We Are Seasonsdev: Prototypes, Postmortems, and Play

The idea hit us during a particularly gruelling crunch on a project that was never going to see the light of day. We were paralysed by the pursuit of a perfect, sprawling design document. So, we torched the five-year plan. Instead of building the next big thing in secret, our editorial team decided to stop chasing perfection and start shipping weird, small browser games every season. No waiting for a Steam page to be perfect, no polishing a vertical slice for a publisher—just a playable link, a deep breath, and a publish button.

Our Mission: Making Seasons the Unit of Creative Shipping

Our rhythm is dictated by the solstices and equinoxes, not by arbitrary fiscal quarters. We are committed to releasing a playable browser game prototype every season, followed swiftly by a brutally honest indie game devlog postmortem. This cycle of creation and reflection is our entire ethos. It’s a discipline inspired by the rapid iteration culture we’ve admired from afar, particularly at UK studios like Mediatonic before Fall Guys exploded into a global phenomenon. Their early game jams and quick-turnaround projects proved that prolific creation is a muscle you have to exercise. We’ve also been heavily influenced by the scrappy, experimental energy at London Games Festival fringe events and the raw, unfiltered creativity thriving on platforms like itch.io. It’s about treating each season as a complete creative loop.

Why Browser Games Win for Rapid Prototyping

For us, the browser is the ultimate liberator. There’s no friction of a download, no app store approval, and no engine splash screen getting in the way of a player’s first click. A browser game prototype collapses the distance between our weird idea and a stranger playing it on their lunch break. It forces us to strip an idea down to its absolute core loop because we can’t rely on high-fidelity textures or lengthy cutscenes to mask a boring mechanic. If it’s fun in a flat WebGL build running on dodgy hardware, it’s probably a solid concept.

The Postmortem Promise: Publishing Failure Loudly

Most studios bury their dead in a graveyard of private folders. We publish ours on the front page. Our postmortem promise means that regardless of whether a prototype was a hidden gem or a complete train wreck, we dissect it publicly. We believe there is more practical knowledge to be extracted from a spectacular failure than from a quiet success. By publishing these lessons, we’re not just documenting our journey; we’re adding to the collective knowledge of the indie game devlog community, showing that a broken mechanic is just a stepping stone, not a career-ending disaster.

Editorial Focus: The Devlog as Design Document

For our editorial team, the indie game devlog isn’t a retrospective diary entry written after the dust settles; it is the active design document. We write to think. When we’re stuck on a mechanic, we draft a post dissecting the problem, often referencing the analytical tone of Rock Paper Shotgun’s postmortem coverage to maintain a critical distance from our own work. The process of explaining a system to a reader forces us to identify the logical gaps we were happily ignoring. We also draw constant inspiration from the bite-sized narrative experiments on platforms like sub-q, which remind us that deep emotional engagement doesn’t require a 40-hour runtime, and from the vibrant chatter at the Bristol indie game dev meetup scene, where a casual chat over a pint can completely reframe a design problem.

Technical Transparency in Every Post

We don’t just talk about feelings; we share the messy reality of the build. Every postmortem includes technical transparency about our Unity WebGL build tricks, from memory management nightmares to getting that shader to compile properly. We’ve learned that the difference between a good prototype and a broken one often comes down to a specific player-facing setting buried in the project settings. By sharing these specific, often hard-won snippets of code and configuration, we hope to save other developers from the same headaches.

Narrative Design Lessons from UK Indie Spaces

The UK’s indie scene has taught us that narrative isn’t just text boxes. We’ve absorbed lessons from GDC Vault talks and local gatherings, applying environmental storytelling techniques to tiny browser game spaces. Whether it’s a game lasting three minutes or thirty, we aim to inject a sense of place and mood that punches far above the technical weight of the prototype, a skill honed by watching the narrative density achieved in interactive fiction and local game jams.

Our Team Approach: Two Developers, One Seasonal Deadline

We are a tiny team of two: a writer-designer and a programmer-artist working remotely across the UK. We don’t have a producer, so the calendar is our boss. We use the annual Develop:Brighton conference as an intellectual reset point, a time to absorb new techniques and reaffirm our commitment to sustainable creation before the next cycle begins. Our workflow is built on the absolute refusal of crunch. By treating the seasonal deadline as a hard, immovable wall, we are forced to cut scope ruthlessly rather than burn ourselves out.

The Two-Person Workflow That Keeps Us Shipping

Our shared Notion board is our single source of truth, but the real magic is in the constraints. Here’s how we keep the pipeline flowing without a project manager breathing down our necks:

• The “Maybe Later” Column: Every cool feature idea goes here immediately. If it doesn’t directly prove the core hook of the prototype, it doesn’t make the cut for the current season.
• Visual-Programmer Handshake: We don’t hand off a massive design bible. We hand off a playable grey-box with bad programmer art first, then iterate on the aesthetics together.
• The Hard Freeze: One week before the solstice, code freeze hits. That final week is exclusively for squashing game-breaking bugs and writing the postmortem draft.

Testing in the Wild: From Coffee Shops to Pubs

A prototype isn’t finished until it survives the real world. We don’t trust our office internet. Before we ship a browser game prototype, we load it up on a laptop and test it on dodgy pub Wi-Fi. We watch strangers in coffee shops try to break the first level without any instruction from us. If the game can’t load quickly or the core interaction isn’t intuitive in a noisy environment where the player might be half-distracted, it’s not ready. This brutal, low-fidelity testing is more valuable than any formal QA session.

Seasonsdev exists to prove that small, seasonal browser game prototypes paired with honest postmortems can build a more resilient creative practice than any five-year plan ever could. We’re not building a monument; we’re cultivating a garden, one season at a time.

FAQ

How often do you release a new game?

We ship a new playable browser game prototype once every season—so four times a year, aligned with the solstices and equinoxes. The full indie game devlog postmortem usually follows within a week of the launch.

What tools do you use to build your prototypes?

We primarily use Unity and target WebGL builds for the browser. For design collaboration and tracking our seasonal deadline, our remote team relies heavily on a shared Notion board to keep scope creep in check.

Do you ever plan to turn a prototype into a full commercial game?

Maybe, but it’s not the primary goal. The mission is to maintain a rhythm of shipping and learning. If a prototype resonates incredibly strongly with the community and the postmortem reveals a sustainable path forward, we might expand it, but we won’t break our seasonal cycle to do so.

Why do you publish postmortems for failed projects?

We believe failure is the most effective teacher. By publishing our failures loudly, we document the specific technical and design mistakes we made, hoping it helps other developers avoid the same traps while keeping our own process honest.