First, a version somebody can buy
The most common mistake in SaaS is building a complete product before the first paying customer.
The scope that looks minimal is usually still too large.
Who this is for
- Companies wanting to sell their own tool on a subscription
- Teams with a working internal tool that has product potential
- Startups before a first round, asked by investors for a delivery plan
What it covers
- Multi-tenancy from day one
Separating customer data is an architectural decision that cannot be added later without a rewrite.
More
We settle the model — shared database or separate — before the first screen exists.
- Subscriptions and billing
Plans, limits, trials and failed-payment handling.
More
Integrated with a payment provider rather than handling cards ourselves — this is a place where building from scratch has no justification at all.
- Onboarding that needs no phone call
If every new customer needs a walkthrough, the product is not SaaS but a service with a portal.
More
Sign-up and first run are designed as a separate, measured process.
- Product metrics built in, not bolted on
Activation, retention and feature use collected from the start.
More
Without them the first product decisions are made on instinct, which is the most expensive way to make them.
In depth
What we don't do
We don't build a full-scope platform before the first customer. We also don't promise that good architecture substitutes for distribution — in the SaaS products we have watched fail, the code was not the cause.
The discovery workshop in SaaS
It matters more here than anywhere else, because the scope doesn't come from an existing process — it has to be invented. We leave it with a list of what is deferred, and that list decides the date of the first version.
Questions about this scope
How long does the first version take?
With scope narrowed to one process and one user type — usually a few months to something you can put in front of a paying customer. Scope, not technology, decides everything here.
Will you build it for equity?
No. We work for a fee, because only then can we honestly say something isn't worth building — and with products that is the most valuable thing a vendor can say.
We have an internal tool. Can it become a product?
Sometimes, but rarely by extending the existing code. An internal tool usually assumes one customer in every layer. We start with an audit that says what can be carried over and what has to be written again.
The parent service and related scopes
Got an idea? Let's talk.
The first call is free. We reply within one business day.