Development

SaaS from scratch: what goes into the first release

The first SaaS release isn't a cut-down product but a product with one working scenario. What's mandatory, what can wait, and what each postponement costs.

August 30, 2026

The first version of a SaaS is almost always discussed as a list of features, but it has to be built from a scenario. The difference is fundamental: a feature list can be cut down to anything and leave you with a product nobody can use, while a scenario either works end to end or doesn't work at all. Below is what's mandatory in the first release, what can be postponed without harm, and what exactly each "later" costs.

A minimum useful product is one end-to-end scenario

Take the main job a client will come to you for, and carry it through to the end with no workarounds. If the product helps track requests, a request can be created, edited, found and closed. If it's about reports, data can be uploaded, viewed and exported.

A sign that the scenario is incomplete: during a demo you have to say "and this part we do by hand for now". One such spot turns the product into a service, and the client pays not for software but for your manual support. Sometimes that's a deliberate strategy at the start, but the decision should be made explicitly, not by default.

A practical technique: describe the first release not as features but as a sentence — "the client logs in and in one session gets this result". Anything not involved in that sentence is a candidate for the next version.

Sign-up, accounts and roles

This is where savings most often backfire. In SaaS, the user is almost never alone: the client has a company, it has several people, and they have different rights.

What's worth building in immediately, even if it seems excessive:

Separating "company account" and "user". Changing this later means rewriting the data model and every query. Even if each company has one person at the start, the organisation entity must exist.
Inviting colleagues by email. Without it, the product doesn't grow inside the client — and that's exactly how SaaS usually grows.
At least two roles: owner and member. A detailed permission system can wait, but the right to delete data and change the plan shouldn't belong to everyone.
Password recovery and email change. Boring, but without them support starts doing it by hand in the database.

What can wait: login via external services, single sign-on for corporate clients, two-factor authentication, an activity log. All of these are added on top of a finished user model without rework.

Plans, free trial, billing

The pricing model affects the code more than the marketing, so it needs to be defined before development, not by launch.

The key question: what do we charge for? There aren't many options, and they fit the product differently.

Per user. The easiest to calculate and clear to the client, but it penalises inviting colleagues — which is exactly what you want.
By volume. The number of records, projects, requests. Requires counters in the product from day one: you can't count retroactively.
By feature set. Then the code gets checks on whether a feature is available on the plan, and they must live in one place rather than being scattered across screens.

Whatever the model, the first release must have: the plan limit itself, clear behaviour when it's reached and an upgrade path to a higher plan. A limit that never triggers isn't a plan, it's a label on the website.

The free trial. Decide in advance what happens on the last day. Is data frozen until payment? Deleted after some period? Does the account drop to a free plan with reduced features? It's not a minor detail: the access logic and the emails sent to the client depend on the answer. Without one, expired accounts live forever and get switched off by hand.

Payment. In the first version, one payment method and one currency are enough. What really is needed right away is correct handling of failed charges and retries, plus closing documents for business clients if you work with them. Complex schemes — proration when changing plans mid-month, promo codes, affiliate payouts — can safely wait.

Isolating client data

This is the part where a mistake can't be fixed with an update. In SaaS, different companies' data sits in one system, and the only thing separating it is your code.

In SaaS, one client's data leaking to another isn't a bug, it's the end of the product. Isolation has to be designed before the first line of business logic.

A practical minimum:

Every table with client data has an organisation ID, and it isn't optional.
The organisation filter isn't added by hand to every query but at a level below which a query can't go. Manual discipline doesn't work here: sooner or later one query gets written without the filter.
Permissions are checked on the server. A button hidden in the interface protects nothing.
Object IDs shouldn't be sequential numbers: swapping in the next number in the URL is the first thing a curious user tries.
Files uploaded by clients are stored with the same separation as database records and aren't served via a direct, predictable link.

Decide on deletion straight away too: what happens when a client leaves. Data is deleted completely, kept for a limited period, or exported to them on request. Being able to take your data with you is also a sales argument. The surrounding perimeter — backups, monitoring, updates — is covered in the security section.

Support and updates as part of the product

SaaS differs from custom development in that everyone runs the same version, and it's yours. That simplifies life and adds obligations.

A support channel. Email or chat in the interface. What matters is that requests land where they'll be seen, and that the client knows when to expect a reply.
Observability. Logs, outage alerts, error tracking. Without them you learn about a breakdown from a client — and not from the first one who ran into it, but from the most patient one.
Zero-downtime deployment. Updates are frequent, and none of them should stop clients from working. That's a requirement for the architecture, not for the release schedule.
Backups verified by restoring. A backup that has never been used to bring the system back up is an assumption, not a backup.
Release notes. A short list of what changed. A cheap way to show the product is alive.

An admin panel for your own team also belongs in the first release: find an account, check its plan, extend a trial, revoke access. Without it, every support request turns into a trip into the database.

What can safely wait

Anything that's added on top of a working foundation and doesn't require reworking the data model can be postponed:

a mobile app — a responsive interface covers the start;
a public API and integrations with external services;
advanced in-product analytics — basic figures are enough;
client customisation: custom domain, logo, custom fields;
multiple languages, if your first clients speak one language;
marketing automation and complex email funnels.

Notice what's not on this list: data isolation, roles, usage metering, backups. That's the foundation, and building it out under live clients costs more than doing it upfront.

Checklist before development starts

One end-to-end scenario is defined that the client completes entirely without your involvement.
It's decided what you charge for, and the product has a counter for that value.
Behaviour on the last day of the trial and on a failed payment is described.
The data model knows about the organisation from the start, not just the user.
Client data isolation is enforced at the database access level, not by developer discipline.
There's an internal support panel and a channel clients can write to.
There are backups, and restoring from them has been tested at least once.

If the answers to points 1 and 2 are vague, it's too early to start development: they determine which counters and limits get built into the product's foundation. How we break such projects into stages is in the SaaS development section.