How To Never Release a Game

Launching a game is easy. Anyone can do it. The real craft, the one that takes years of quiet dedication, is almost launching, indefinitely, with total commitment.

I'm something of an expert. Tapestria, the AI RPG I've been building, has been a few months from launch for considerably longer than a few months. So before I tell you what I think lean development actually means for games, let me give you the method I perfected first: how to guarantee you never ship.

It starts with scope. Cutting scope is the hardest decision a good product manager ever makes, and I was never a good product manager. I'm a software engineer, so I never had to make it. That, more than anything, is the qualification that made me so good at not launching.

Think big, then bigger. Why build a city when you can build a continent? My first design for Tapestria was a whole continent of distinct regions. Why offer four playable species when D&D ships an entire catalog? Why two kinds of quest when you can promise dozens? Every cut is a small admission of mortality, and a true never-launcher refuses to admit it.

Follow every feature wherever it leads. Scope is fractal. Add a tavern and now you need an innkeeper; the innkeeper needs goods to sell; the goods need prices; the prices need an economy; and the economy needs gold, supply, demand, and prices that swing every time someone buys or sells. Now you're balancing a market. Cutting scope inside the new frontier is heresy. Let it grow, exponentially. The trick is simply to never resist.

And if you truly want to never finish, build the whole thing on a language model. It feels like magic at first. You describe a tavern and it appears. But players will look for exploits and bypass your prompts, because a prompt is a polite suggestion, not a law. So you add real mechanic rules to constrain the model. Except mechanic rules have corner cases, endless ones, and each one has to be covered, then explained back to the LLM so it knows when to call the right tool, which surfaces new corner cases, which need new rules, which need new explanations.

What lean was supposed to be

Lean is the gospel of modern software. Build the smallest thing that tests an assumption, put it in front of a real user, learn, iterate. Small, fast cycles. In the age of AI those cycles are faster than ever, especially for a solo founder running the whole pipeline: conception, implementation, marketing. It also does something for morale. When you see steady, visible progress and a constant trickle of feedback, it's easier to keep going.

For a SaaS it's a perfect fit. You start with a pain, ship an MVP and your clients tell you within a week whether you were right. Games don't work like that.

Why lean seems not to apply to games

The first problem is that you're not solving a pain, you're trying to entertain. There's no clean metric for fun and it's nearly impossible to have useful feedback on what the game should look like.

The second problem is worse: the value is invisible until the thing is nearly complete. A SaaS at 60% is a smaller SaaS with less features but if scoped correctly, still works. A game at 60% isn't a smaller game. It's just not fun yet. And the part that eats the most hours, the engine, has no surface a player ever sees. It's like pouring the foundation of a skyscraper. You work incessantly, and from the outside it looks like nothing is happening.

So you can't show progress, you can't get feedback, and the morale lean was supposed to protect quietly dies. For a while I decided lean just doesn't work for games, and kept building the monolith in the dark.

That conclusion is wrong. I didn't have the wrong philosophy. I had the wrong unit of iteration.

Find the fun first

The lean equivalent in games already exists, and it has a name: the vertical slice. One small, complete, playable path that cuts through the entire stack and tests whether the core loop is worth building. People usually call the discipline behind it "find the fun first."

The standard advice has a blind spot, though. "Find the fun with a cheap, disposable prototype" assumes you can prototype the mechanic cheaply. Sometimes you can't, because the mechanic is part of the whole platform.

The thing I most wanted Tapestria to do was let the world remember and react: a simulated theory of mind and a relationship graph the game reasons over, so that what a character knows and wants depends on who they are and what happened around them. You can't fake that with a mockup or a single prompt. There's no disposable version of it; the thing you'd build to test it is most of the thing itself. So I built it.

It took months. And once it worked, I was in the same hole I'd warned about at the start: a powerful engine, invisible from the outside, with no actual game on top of it. I had poured the foundation and forgotten that nobody can see a foundation.

Like Hannibal, eat the problem piece by piece

When I finally accepted I had to slice, I thought I'd found the answer: break the engine into pieces that could each ship and be shown on their own. A combat demo. A map-building demo. An investigation demo. Three small, finishable, demoable things.

It was a trap, and a subtle one. It was hard to see precisely because it had all the surface features of the right answer. Those three things were finishable and showable. But they were features, not the game: three detachable mechanics that didn't grip anyone alone and, worse, didn't talk to each other. A polished combat demo tells you combat works. It tells you nothing about whether Tapestria is worth playing.

I'd confused "shippable" with "the soul." A real vertical slice isn't a sampler of your mechanics. It's a slice of the actual thing, the core loop the whole vision rests on. It must show what makes your game different from all the million others.

The cut that actually mattered

So I cut again, and this time toward the vision instead of toward what was easy to package.

Tapestria was never about combat or maps. It's about emergent lore: a shared, persistent world whose story grows out of what players do inside it. Once that's the target, the cuts get brutal and obvious. I reduced the mechanics to only the ones that already existed. I threw out every quest type but one: a single generic, freestyle quest, where the LLM looks at an NPC, its worldview and its surroundings, and decides what that NPC wants. Every NPC has one. Complete it and a new one is generated, so every NPC always carries a drive and the story never stalls for lack of something to do.

Then I cut world generation down to two loops:

• A player can spend a pack of resources to follow a trail and discover a new location. They describe what they see, and the model generates the place and connects it into the world graph.
• A player can search a location for an NPC. They describe who they're looking for, and the model generates that character and adds them to the place, consistent with the world around them.

That's the whole game right now. And here's what the three demos could never do: these loops feed the same world. The location you follow a trail to can hold the NPC you went looking for, who hands you the quest that sends you down the next trail. Every action compounds into one growing, shared story. That compounding is the fun, I expect at least, and it's exactly what three disconnected demos couldn't produce, no matter how polished each one got.

The combat engine and the map builder didn't die. I'm still releasing them. They're useful and I already did the work. I just stopped treating them as the plan. They came out of building the game, but they're not the reason anyone would play it. For a while I had those two things confused.

So, does lean work for games?

I think it does. I just had the wrong idea of what to cut. Cutting scope isn't something you do once and you're done with it. It's something you keep doing, and the hardest cuts aren't the obvious bloat. The hardest ones are the parts that actually work, like my three demos, that just aren't the game. I cut those last, because they looked like progress.

There's also a reason this matters past shipping dates. The thing lean really gives you is morale. When you can see progress and show it to someone, you keep going. Building a game the slow monolithic way kills that. You spend months on things nobody can see and you forget why you started. Cutting down to one loop that actually works is how I got that back. It's small and rough, but I can finally put it in front of someone and watch them play.

I've been an expert at not launching for a long time. I'm trying to get worse at it.