Cutting Features: What Scope Discipline Actually Costs

Most dev logs list what got built. This one is about what gets deleted, and about the part nobody budgets for: deletion is not free. If you run a small team, the useful question here is not which features we drop but the one underneath it — how much work do you owe an idea before you are allowed to walk away from it?

We build for mobile and web, currently across two shipped titles: Kart Üçlüsü and Thornguard: Tower Defense. Different genres, same constraint — a small team can prototype far more than it can maintain. What follows is the reasoning we apply, written as a method rather than a changelog.

A Feature Costs the Most After It Starts Working

Build cost is the number everyone estimates, and it is the smallest one. The real bill arrives afterwards, and it is recurring:

• Layout: every new screen has to survive every aspect ratio you support, from a narrow phone to a browser window someone resized to a postage stamp.
• Localization: new strings, and new strings that break your layout in a language with longer words.
• Save data: once a system writes to the save file, removing it later means a migration, not a delete.
• Onboarding: anything a player must be taught competes for the first two minutes with everything else you must teach.
• QA surface: each toggle multiplies the states you have to test before every release.

For us there is a fifth axis, because the two games share tooling — a point we wrote about in Two Games, One Codebase. Shared code makes building cheaper and makes keeping things more expensive: a system that only one game needs still shows up in the other project's build, its dependency graph, and its regression tests. Shared code turns "one team's feature" into "everyone's maintenance".

So the honest framing of any scope decision is not can we build this. It is are we willing to pay for this every month for as long as the game is live.

Pattern One: Ornament That Fights the Read

The most common cut in a card game is decoration, and it is the hardest one to argue for cutting because it is the part that looks good in a screenshot. We covered the specifics in Card UI Readability vs Aesthetics, but the scope lesson is separate from the visual one.

Ornament fails in a very particular way: it does not break anything. Nothing crashes, no test goes red, and in a five-minute demo it reads as polish. It only fails at the pace real players actually play at, where a card has to be identified in a fraction of a second and a dealing flourish that feels charming on the first hand feels like a toll booth on the fortieth.

That is why this category needs a rule instead of a judgement call. Ours is simple: if a visual element competes with the information the player needs to make the next decision, the information wins. Cutting it makes the game faster and duller in equal measure, and you have to say the duller part out loud. What you gain is session pace and fewer misreads. What you lose is personality, and personality is not a rounding error — a card game that reads perfectly and feels like a spreadsheet has traded one problem for another.

Pattern Two: Systems That Want to Be Their Own Game

Tower defense attracts sub-systems the way a fridge attracts magnets: meta-progression trees, hero units, deck-building over towers, level editors, endless modes. Each of them is defensible in isolation. Each of them is also a second game, with its own balance curve, its own tutorial, and its own failure states.

The warning signs are structural, and you can spot them before you write the code:

1. The design notes for the sub-system are longer than the notes for the core loop.
2. Balancing the main game now requires re-balancing the sub-system, and then re-balancing the main game again because the sub-system moved.
3. The sub-system's best version makes the core loop less interesting — a meta-progression that lets players out-level a wave has quietly deleted the wave.

Point three is the one worth internalising. A feature that improves the game's surface area while weakening its central decision is not a feature that needs more work. It is a feature that is working exactly as designed, against you.

Pattern Three: Features You Cannot Tune With the Data You Have

Some ideas are fine in principle and impossible in practice at your size. Adaptive difficulty is the classic one: a system that quietly adjusts to the player only earns its keep if you can observe whether it helped. We tune difficulty by reading the shape of the curve by hand rather than from a dashboard, which is the whole subject of How to Read a Difficulty Curve Without Telemetry Data.

If a feature needs measurement infrastructure to be tuned, then it is really two features, and you are only estimating one of them. That is a scoping question, not a design question, and answering it early saves the more painful version of the conversation later.

Deletion Has Its Own Bill

Here is the part that surprises people the first time: removing a finished feature is often more work than shipping a small one. Once a system has touched save data, UI layout, localization files and analytics events, git revert stops being an option — you are writing a migration and re-testing screens that had nothing to do with the feature.

The tempting shortcut is to leave it in, switched off. It looks like keeping your options open. It is actually a permanent tax:

// Parking a cut feature behind a runtime flag looks cheap.
// It is not: both branches stay in the build, the QA matrix,
// and every refactor for the rest of the project's life.
public static class Features
{
    public const bool ExtraMode = false;
}

void Start()
{
    if (Features.ExtraMode)
    {
        BuildExtraModeUI();
    }
}

If the decision is genuinely reversible next sprint, a flag is fine. If it is not, delete the code and trust version control. The branch you keep "just in case" is the branch that breaks silently six months later, in a build you already shipped.

There are two costs that never appear in the ticket. The first is human: someone built that thing, and cutting it lands differently than cutting a line from a backlog. The second is knowledge — if you delete the work without writing down why, the same idea comes back in four months with a new name and gets built again by someone who was not in the room.

How Long Do You Owe an Idea?

The honest answer is that time spent is the wrong unit. Sunk cost reasoning says the correct comparison is remaining cost against remaining value, and that is true — but it is also the advice that makes teams quit too early, because almost every feature is bad in its first playable state. Rough edges are not evidence.

The distinction that actually works is between bad execution and bad fit. Bad execution is fixable: unclear feedback, wrong pacing, poor readability, one missing affordance. Bad fit is not: the feature works and the game is worse for it.

The test we use is a thought experiment, and it takes about a minute. Imagine every known bug fixed, every animation polished, every string rewritten. In that finished version, do you still want it in the game? If the answer is no, keep working on it for exactly zero more hours — no amount of polish will change a fit problem. If the answer is yes but you are not sure it is worth the cost, that is a scheduling decision, not a design one, and it belongs in a backlog rather than in a debate.

Three checkpoints keep this cheap. Paper or a rough prototype should show whether the feature answers a question the core loop is actually asking. A playable version should be interesting without a designer standing over the player explaining it. An integrated version should make the rest of the game better, not merely bigger. Failing the last one is the expensive case, and it is the one where teams most often keep going because the work is nearly done.

Keep a Cut Log

Whenever something gets dropped, write four lines somewhere permanent: what it was, why we built it, why it went, and what would have to change for it to come back. That last line matters most — a feature cut because it needed telemetry is a different case from a feature cut because it hurt the core loop, and only one of them deserves a second look.

One caution to end on, because scope discipline has a failure mode too. A team that gets good at cutting can cut its way to a game that is clean, legible, testable and completely forgettable. Every deletion removes a risk and also removes the player who would have loved exactly that thing. The list of what you deleted is a design document; read it occasionally and check that you still recognise the game underneath.