What makes it SaaS rather than an internal tool
An internal application has one customer, and you are it. You can define the process, train the users, and fix a bad assumption by telling everyone to do it differently on Monday.
A SaaS product has many customers who do not share your assumptions. Each one needs their own data kept separate from everyone else's, has to be able to sign up and get working without you on a call, and will leave if the monthly charge stops being worth it. Those three facts shape nearly every technical decision below.
If you are not sure which one you are building, the website or web application guide covers the step before this one. Plenty of good businesses need an internal tool and never need a product.
Validate it before you build it
The most expensive SaaS products are the ones built in full before anyone was asked to pay. The failure is rarely technical: the software works and nobody wants it at that price.
Cheap ways to find out first:
- Talk to ten people who have the problem, and ask what they do about it today rather than whether they would use your idea. Everyone says yes to a hypothetical.
- Find out what they currently pay, in money or in hours. A problem nobody is already spending on is a hard first sale.
- Run the process manually for one customer. If you can deliver the outcome with a spreadsheet and an afternoon, you have both a first customer and a specification.
- Take money before the product exists, even a deposit. It is the only question whose answer means anything.
The thing to be most careful about is building for yourself. Software that solves your own problem perfectly is a good internal tool and often a product with exactly one happy customer.
What goes in the first release
A first release should let one kind of customer do one valuable thing, pay for it, and come back next week. Everything else is a later decision, and most of it will be decided differently once real people are using it.
What usually has to be in version one:
- Sign-up, sign-in, and password reset.
- The single workflow the product is actually for.
- A way to take money, even a manual invoice at first.
- Enough of an audit trail to answer a customer asking what happened to their data.
What can almost always wait: team invitations, granular permissions, single sign-on, an admin dashboard with charts, a public API, native mobile apps, in-app onboarding tours, and a settings page for preferences nobody has asked for yet.
The exception is the next section, which is the one architectural decision you cannot leave until later.
Multi-tenancy: the decision you cannot defer
Every record in a SaaS product belongs to a customer, and the system has to enforce that boundary rather than rely on the interface not showing the wrong button. Retrofitting that into an application that was written for a single customer is close to a rewrite, which is why it belongs in the first week.
Two questions decide the shape of it.
Is a customer a person or an organisation? If several people from the same company will share data, the account belongs to the organisation and people belong to the account. Starting with one account per person and discovering later that customers want teams is one of the most expensive corrections in this list.
Does one customer's data need to be physically separate? For most products, one database with a tenant identifier on every record is right, and the boundary is enforced in the data layer so no query can accidentally cross it. Separate databases per customer are occasionally required by a contract or a regulator, and they make every future change harder, so do that only when someone is actually requiring it.
Accounts, roles, and invitations
Do not build authentication. Password storage, reset flows, session handling, two-factor, and the eventual demand for single sign-on are all solved by services that cost less than the time to get them wrong, and getting them wrong is a breach rather than a bug.
What is worth your own thought is the layer above it. Roles should be rules about records, not a list of screens: an owner sees everything in their organisation, a manager sees their location, a client sees only what belongs to them. Written that way they stay correct when you add features; written as a list of hidden buttons they do not.
Then the parts people forget: inviting a colleague who does not have an account yet, transferring ownership when the person who signed up leaves the company, and removing access so that it is actually gone rather than merely hidden.
Pricing shapes the software
Decide how you charge before the build, because the pricing model is a data model. Per seat means counting and enforcing seats. Per usage means metering something accurately enough to put it on an invoice and defend it. A flat fee per month is the simplest thing that can possibly work and is underrated for a first version.
Use a payment provider for the whole of this and resist the urge to build a billing system. What you are buying is not the card form, it is everything around it:
- Trials, upgrades, downgrades, and the proration arithmetic nobody enjoys writing twice.
- Failed payments and retries, which is a surprising share of lost revenue if nothing handles it.
- Invoices and receipts that a customer's accountant will accept.
- Sales tax and VAT, which depend on where your customer is rather than where you are.
- A record of who is entitled to what right now, which your application reads rather than keeps its own copy of.
The one thing to own yourself is the mapping from a subscription to what the product unlocks. Keep it in one place. Entitlement logic scattered across the code is how customers end up with access they are not paying for, or locked out of something they are.
When money moves to other people
Charging your own customers is routine. Paying other people through your platform is a different product, and it should be named on day one rather than treated as a feature for later. A marketplace, a booking platform that pays providers, or anything where you sit between two parties falls into this.
What comes with it: verifying the identity of the people being paid, holding funds and scheduling payouts, handling refunds and chargebacks after money has already moved on, and deciding who is legally the merchant of record. Payment platforms have products for exactly this, and using one is almost always right.
Paganki is a built example: a multi-tenant platform with Stripe Connect payouts, running in five languages.
The work that starts on launch day
A SaaS product is a service, and the build is often the smaller half of what it costs over five years. The parts that are easy to leave out of a budget:
- Hosting, a database, and backups that scale with the number of customers.
- The metered services underneath: email delivery, file storage, authentication, payments.
- Security updates to everything the product is built on, which are not optional once you hold other people's data.
- Support, including the question that arrives at 7pm because someone cannot finish their work.
- Restoring one customer's data without touching anyone else's, which is a thing you should have tried before the day you need it.
- Changes, because a product that is used generates requests.
If the plan has no budget for the second year, build something smaller. An abandoned product with paying customers on it is worse than never shipping.
What breaks at a hundred customers, and at a thousand
Early problems are usually about correctness, and later ones are about one customer affecting another. The second kind is worth designing against early, because it is cheap to prevent and disruptive to fix.
The usual order things break in: reports that were fast over one customer's data become slow over the largest customer's; a long-running job started by one customer delays everyone else's, so work moves to a queue; email starts landing in spam once volume rises, so sending needs its own domain and reputation; and support becomes impossible without a way to see what a specific customer actually saw.
None of these needs solving in version one. They need to be possible without rewriting what you built, which mostly means keeping tenant boundaries honest and not putting slow work in the request that a person is waiting on.
Selling beyond one market
If customers outside your first market are part of the plan, the cheap moment to allow for it is at the start. Retrofitting a second language into a running product means touching every screen, every email, and every error message, which is why it so often does not happen.
Three things to decide rather than discover: whether the interface needs more than one language, whether you charge in more than one currency, and whether tax is handled by your payment provider or by you.
In South Florida the bilingual case is normal rather than exotic. A product sold in both English and Spanish needs both in the whole experience, including the order and notification emails, which is the part usually left in English.
Getting it built
If you have validated the idea and want the first version built properly, with the tenancy, accounts, and billing decided deliberately rather than discovered, that is what my web application service does. The first conversation is about the process and the customers, not the stack.
Built examples: Paganki is a multi-tenant SaaS platform with Stripe Connect payouts across five languages, the Athlean-X Portal delivers purchased products to thousands of signed-in users as an offline-capable progressive web app, and Parking Operations Analytics turns live transaction data into per-shift revenue reporting across multiple garages.