The first ninety days of a SaaS build, in order
Sequencing decides whether a product ships. Building the interesting parts first and the foundations later is the most reliable way to be eighty per cent finished forever.
Key takeaways
- Do tenancy, authentication, the core data model and deployment first; tenancy is hardest to reverse.
- Build one workflow completely, including empty states and failures, before starting a second.
- Meter usage from the start even when billing a flat rate, so the pricing model can change later.
- Audit logging cannot be backfilled; an enterprise buyer asking for history you never recorded is an unrescuable deal.
In the first ninety days, build the boring foundations before the interesting features. Accounts and tenancy, authentication, the core data model, one complete end-to-end workflow, then billing. Teams that start with the distinctive feature and add foundations later reliably end up rebuilding, because the foundations change assumptions the feature was written against.
Weeks one to three: foundations
- Tenancy model, with isolation enforced at the database layer rather than in application code. This is the decision hardest to reverse, so make it deliberately and first.
- Authentication, using a maintained provider rather than writing it. Password handling, session management and account recovery are solved problems where a mistake is expensive.
- The core data model for your primary entity. Get the shape right before anything depends on it.
- Deployment and environments, so shipping is routine from week one rather than an event.
Weeks four to eight: one workflow, complete
Build the single most important user journey end to end, including the parts nobody demonstrates: empty states, error handling, permissions, and what happens when something is slow or fails. One complete workflow teaches you more about the architecture than five partial ones, and it is the only way to find the assumptions that turn out to be wrong.
Resist adding a second workflow until the first is genuinely finished. Partially complete features accumulate into a product that demonstrates well and cannot be released.
Weeks nine to twelve: billing and the release path
Billing is always harder than expected: proration, failed payments, plan changes, tax handling, and invoices customers will send to their finance department. Use a billing provider rather than building it, and meter usage from the start even if you bill a flat rate, so that changing the pricing model later does not require re-instrumenting the product.
In the same period, put in place error monitoring, audit logging and the analytics events for your activation funnel. Audit logging in particular cannot be backfilled, and an enterprise buyer asking for history you never recorded is a deal you cannot rescue.
What to defer without guilt
Administrative dashboards for a customer base that does not exist, integrations nobody has requested, a settings screen with more than a few options, and any optimisation for a scale you have not reached. Each is defensible individually and collectively they are why products take a year to reach a first customer.
The checkpoint at day ninety
One real customer using one complete workflow in production, with billing working and the activation funnel instrumented. That is a product you can learn from. A larger feature set with no customer is a prototype with better marketing, and the difference matters because only one of them tells you whether to continue.
Building the interesting parts first is the most reliable way to be eighty per cent finished forever.