The MVP question nobody asks: what happens if we remove this?

Feature lists are not scope

Every founder arrives with a list. The list is not the problem — the problem is that everything on it feels equally necessary when you wrote it yourself.

Our job in week one is not to estimate the list. It is to shrink it.

The removal test

For each feature we ask one question: if we remove this, does a real, named pilot customer stop paying?

Not "would it be worse". Not "would they complain". Stop paying. On our last MVP, 31 features went in and 9 came out the other side.

The features that fail this test are not deleted — they are dated. They go on a list with a trigger: "build this when we have 50 accounts" or "build this when support gets ten of these a month".

What always stays in

Three things survive the test even though no customer asks for them: multi-tenancy done properly, real authentication and roles, and billing integrated from day one.

Retrofitting any of those after a funding round costs roughly three times what it costs upfront, and the rewrite always lands in the same quarter as your first serious growth push.

The handover trap

The last mistake is treating handover as a document. It is not — it is an overlap.

We budget two weeks where the client's own engineers ship real features with us still on call. If they cannot ship without asking us, the MVP is not finished, whatever the invoice says.

If any of this is a live problem rather than an interesting read, say so. We would rather have a specific conversation than a general one.

— Sayan Saha, Founder