Software
What a first SaaS version should include
A first SaaS version should do one job better than the spreadsheet or tool it replaces, on one plan, with self-serve sign-up, subscription billing and separated accounts working from day one. Everything else waits until real accounts show what to build next.
The short version
A first version exists to answer one question: will someone pay for this? Everything in it should help answer that question, and everything that does not can wait.
One job, one plan, one way through
Pick the single job the product does better than the spreadsheet or tool it replaces. One pricing plan. One path from sign-up to that job being done.
It will feel too small. That is the point. A narrow product that people pay for tells you what to build next; a broad one that nobody pays for cannot tell you which part failed.
What has to work on day one
- Self-serve sign-up and onboarding, so an account can start without a call.
- Subscription billing through a PCI-compliant provider, so card details never touch your application.
- Separate tenants that cannot see each other’s data, enforced in the database rather than on each screen.
- Admin tooling, so support does not need a developer to answer a customer.
- Export and deletion of an account’s data, because GDPR obligations are cheaper to build than to promise.
Decide the billing states before the first screen
The application is rarely the hard part. Billing states are: a trial that lapsed, a card that failed on the third retry, a team that added four seats mid-month, an account that downgraded and must lose exactly the right features and no others.
Decide those rules first. Changing them after there are paying accounts means migrating money.
Measure the three numbers that decide the roadmap
Activation: does a new account reach the moment the product is useful? Usage: which parts are used every week, and which were a guess? Churn: who stops paying, and when?
Measured from launch, those three turn the roadmap into a response to what accounts actually do, released weekly rather than planned a year ahead.
Then iterate, or stop
After the first version, iteration can be bought month by month and stopped whenever it stops paying for itself. That is how our SaaS product development runs: a fixed-price first version, then weekly releases against real usage.
If what you need is an internal tool rather than a product to sell, start with when a spreadsheet should become an application.
Article FAQs
Still have questions?The short answers.
Should billing be built into the first version of a SaaS product?
Yes. Paying is the only reliable test of demand, and adding billing to a product that already has users means migrating accounts and money. Wire subscription billing through a PCI-compliant payment provider from day one, even if there is only one plan.
How narrow should a first SaaS version be?
Narrow enough to describe in one sentence: one job, one plan, one way through it. A product with four half-finished features tells you nothing about demand, while a narrow one that people pay for tells you exactly what to build next.
What should a SaaS product measure from launch?
Activation, usage and churn, measured where they happen: whether a new account reaches the moment the product is useful, which features are used every week, and which accounts stop paying. Those three decide the roadmap better than a feature wishlist.
