Cutting a feature during MVP scoping feels final. It gets written down, nobody objects, and the meeting moves on. But a cut that isn’t specific enough isn’t really a decision. It’s a placeholder, and nobody has said who gets to fill it in.
In MVP scoping, a cut needs an owner, not just a meeting
Most scoping meetings produce a list: build this, skip that. The list feels like a decision, but it isn’t one yet. A real cut has a name attached to it, a closed ticket, and a line in the spec explaining why it’s out. That line also says what would have to change for it to come back in. Without that, “we’re not doing admin roles for v1” is just something someone said once. Sentences like that get forgotten the moment a support request makes the missing feature feel urgent.
Engineers default to building the thing in front of them. Say a ticket reads “add user management,” and nobody wrote down that granular roles were cut. The engineer picks up the familiar pattern anyway: a roles table, a permissions check, three tiers nobody asked for. That isn’t scope creep in the usual sense, since nobody added a feature to the plan. The plan just never closed the door on it.
The stub that becomes permanent
A door left open gets walked through eventually. This is where an unowned cut resurfaces: as a stub. Someone needs to test the signup flow, so they add a fake multi-tenant switch to simulate two customers. Someone needs sample data, so they wire up a CSV export “just for now.” Three weeks later, that stub is load-bearing. Another feature gets built on top of it, a demo shows it to an investor, and removing it becomes a conversation nobody wants to have.
More discipline in planning isn’t the fix. That’s the answer most teams reach for, and it’s the one that doesn’t survive deadline pressure. The fix is treating a cut as something that has to be defended every time it threatens to come back. It’s not something decided once and assumed to hold. In practice, that’s a small process change. When a stub appears for a feature that was cut, code review flags it. The review note says the feature is out of scope and asks for confirmation before merging. It doesn’t get waved through just because it’s convenient this sprint.
What “keep” has to commit to
Stubs are what happens when a cut goes unwatched. A keep decision fails for the opposite reason. It’s usually the harder half of scoping to get right, because “keep” on its own says too little. Keeping authentication in the MVP doesn’t say whether it’s email and password or a third-party identity provider. Keeping notifications doesn’t say whether they’re transactional emails or a queue-backed system built to scale to push and SMS later. Each of those choices locks in infrastructure. Infrastructure is the one layer where a shortcut taken in week two can still cost the team a redesign a year later.
A keep decision that doesn’t specify the shape of the thing being kept isn’t really a decision. It’s a placeholder with a due date attached. That’s how a team ends up with three different session-handling approaches across one codebase, none of them chosen on purpose.
Who fills the gap when nobody specified it
The stub nobody questioned and the keep nobody specified share the same failure. Neither one was ever actually decided, so somebody else decides by default: whoever is building that week, under whatever deadline is closest. They don’t choose maliciously. They choose the version that’s easiest to test right now, not the version that fits where the product is going. Every sprint that passes without revisiting an ambiguous item is a sprint where that default choice gets a little more permanent.
Fractional CTOs who sit in these planning meetings across several companies at once tend to notice the pattern early. They see the same half-built stub turn into the same stuck feature, company after company, and the cause is rarely a bad decision. It’s a decision that was never specific enough to hold. Kody Doherty, Fractional CTO, sits in these scoping meetings for founders.
The question to ask before the ticket is written
The gap gets filled the moment it’s left open. So the real question has to get asked before the ticket exists, not after a stub already fills it. Before a feature gets cut or kept, the question that matters is narrower than “do we need this.” It’s “what would it take to build this halfway, and are we willing to ban that.” If the answer is no, the item needs a closed ticket and a named owner responsible for keeping it closed. A note in a doc nobody reopens isn’t enough.
Scope discipline isn’t about saying no more often. It’s about making the no specific enough that nobody can quietly build around it. A cut or a keep that gives way in the first sprint under pressure had a line in a doc and a nod in a meeting. It was never actually decided.