An MVP, not a degraded version
A minimum viable product is not your product with features removed. It is the smallest complete path that lets a real user get real value and pay for it. Everything on that path must work properly; everything off it can wait.
That distinction decides the whole project. Teams that build a smaller version of everything ship something nobody can use. Teams that build one complete path ship something a customer will pay for, and learn what to build next from actual usage rather than from assumption.
What every SaaS needs, and what it costs in time
Beneath the features that make your product distinctive sits a layer every SaaS requires, and which founders systematically underestimate:
- authentication, password reset, and invitations to a team account;
- roles and permissions, the point where a user must never see another customer's data;
- subscriptions: plans, trials, upgrades, downgrades, failed payments, cancellations;
- an admin back-office, without which every refund and every account fix goes through a developer;
- transactional emails that actually arrive rather than landing in spam;
- the measurement built into the product, so you know your recurring revenue without a spreadsheet.
The decisions that get expensive if taken too late
Three choices are cheap at the design stage and costly afterwards. Multi-tenancy first: whether customer data is isolated by row, by schema or by database determines the data model and every migration that follows. Changing it later touches the whole data access layer.
Then the billing model: per seat, per usage, or flat, it shapes what you must measure from day one, and retrofitting usage metering into a live product is painful. Finally GDPR: what you collect, where it is hosted, how long it is kept. Handled during the build it is a set of decisions; handled after, it is a rework.
Running the product after launch
A SaaS is not delivered, it is operated. After launch the questions change: which users activate and which drop out, which plan actually converts, where recurring revenue leaks. That is what the back-office and the built-in measurement are for.
I stay available after release for fixes, iterations and the technical decisions that come with growth. The alternative, a product handed over with nobody able to change it, is the situation I am most often called in to repair.
When another solution will fit better
- Projects without a decision-maker. A SaaS involves constant trade-offs; without someone able to settle them, timelines don't hold.
- A complete SaaS in three weeks. If that is the constraint, we cut scope, never the estimate.
- Taking over an existing SaaS without an audit. No fixed price before seeing the code.
- Fundraising and investor pitching. I build the product; I don't raise the money.
