From MVP to product: validating a SaaS without burning the budget

The first version needs one feature that solves a problem someone already pays to solve, even if they solve it by hand today. Billing, admin panels and integrations can be done manually for the first few months. Authentication and backups cannot.

The pattern repeats with striking regularity: six months of building, a launch, and the discovery that the feature which consumed half the time is used by nobody, while the thing customers actually wanted was never on the list.

The cut almost nobody has the nerve to make

List everything the product should have. Now pick one feature, the one that, if it were the only thing that existed, would still make someone pay. That is the launch. Everything else is a waiting list.

The pushback is always the same: “but nobody will use it without reporting”. Maybe. Except that is a hypothesis, and it costs six weeks to test by building or one conversation to test by asking.

What can be done by hand at the start

• Account creation. For the first twenty customers, doing it manually is half an hour a week. And it buys you a conversation with every new customer, which is worth more than the time saved.
• Billing. A manually generated payment link works. Automated recurring subscriptions can wait until you have recurring customers.
• Reports. A database query and a spreadsheet emailed over. If nobody complains about the delay, the report was not a priority.
• The admin panel. For the first months, the admin panel is the database.

What you never cut

• Authentication done properly. Leaking twenty customers’ data kills the product before its first year.
• A restored backup. Losing your first customers’ data is the end, and those are precisely the people still deciding whether to trust you.
• Separation between customers. One customer seeing another’s data is the worst possible failure in SaaS. If the product is multi-tenant, isolation is structural and has to be right from the first line.
• Event logging. You need to know what users do, or you will prioritise by opinion.

Multi-tenancy is the decision you cannot postpone

If each customer has their own users and isolated data, that decision has to be made before the first table. Retrofitting it later is effectively a rewrite, because every query in the system changes.

For the vast majority of cases, a single database with a tenant identifier on every table and a mandatory filter on every query works well, costs little and scales a long way. Separate databases per customer only pay off when there is a regulatory requirement or very large customers paying for physical isolation.

Charge from the first customer

A free product validates nothing. People love free things and use them once. The signal that matters is the second payment, because it means the value actually showed up.

If the price is still uncertain, charge something clearly low and say it is an early customer price. That preserves your room to adjust later and already produces the information you need: does anyone reach for their card over this?

The numbers that tell you it is working

In the first months, three figures are enough.

Activation: of the people who sign up, how many reach the core feature at least once? If it is under half, the problem is the first experience, not the product.

Week-two return: how many come back without being reminded? That number predicts the future better than any interview.

Churn with a reason: every cancellation deserves one question. The answers that repeat are your priority list, already sorted, for free.

A beautiful dashboard with twenty metrics in month one is a distraction. Those three decide whether the product continues.

Talk to your users, properly

With twenty customers you can talk to all of them. Not by survey, by conversation. The sentences that show up in three different customers are your next release. The ones that show up in only one go on the list and wait.

That is the only reliable mechanism for not building the expensive feature nobody asked for. And it costs a few hours a week rather than six weeks of development.