Custom Software
How to build a SaaS application
The technical side of SaaS is well understood. The expensive mistakes come from building too much too early, and getting a few key decisions wrong.
Building a SaaS application is less a question of code than of sequence. Most failures come from spending a year on a product before finding out if anyone will pay for it. This guide covers the order we’d do things in, and the technical decisions worth getting right the first time.
1. Validate before you build
Talk to people who have the problem. Not friends, and not people who’ll say something polite. Ask how they deal with it now, what that costs them and what they’ve already tried. People who’ve hacked together their own spreadsheet or who already pay for a poor alternative are the best sign you could get.
Then try to get a commitment. A letter of intent, a paid pilot or a deposit tells you far more than “sounds interesting”. A clickable prototype is often enough to have that conversation, and a little manual work behind the scenes can deliver the service for your first few customers without any automation at all.
2. Decide what version one is
Pick one kind of customer and one painful problem. Version one should solve it completely, even if it does nothing else. It generally needs:
- Sign-up and login, plus password reset.
- The single core workflow.
- A way to take money, even if it’s manual invoicing at first.
- Basic analytics, so you can see what people do.
- A simple admin view, so that you can support customers.
It usually doesn’t need a mobile app, complex roles, an integrations marketplace or custom reporting. Keep a list of those requests, as the things customers repeatedly ask for will tell you what comes next.
3. Choose boring technology
Your competitive edge won’t come from your web framework. Pick something mature, productive and easy to hire for, such as Laravel, Rails, Django or Next.js, along with PostgreSQL or MySQL. A single well-organised application will take you a very long way. Microservices solve problems for large organisations, and you don’t have those yet. They’d just slow you down.
4. Get multi-tenancy right
This is one decision that’s worth thinking about up front. There are three common patterns:
| Pattern | Pros | Cons |
|---|---|---|
| Shared tables with a tenant ID | Cheapest, simplest to run and update | One missed filter can leak data, so needs strong safeguards |
| Separate schema per tenant | Better isolation | Migrations take longer as tenants grow |
| Separate database per tenant | Strongest isolation, can suit enterprise and data residency needs | Most costly and complex to run |
Most products start with shared tables. If you do, enforce tenant scoping centrally in the framework, not by remembering a filter on every query, and write automated tests that specifically try to read another tenant’s data. A leak between customers is the sort of incident that can end a young B2B company.
5. Model accounts properly from day one
Even if version one has only single users, design with an organisation that has members. Retrofitting teams onto a user-based data model is one of the most common painful migrations in SaaS. Roles can start simple, like owner and member, as long as the structure is there.
6. Don’t underestimate billing
A Subscribe button is the easy part. Then come upgrades and downgrades mid-cycle, failed payments, annual invoices, VAT, refunds and cancellations. Use Stripe Billing, or a merchant of record such as Paddle, which handles global sales tax in exchange for a higher fee. Keep your pricing logic in one place, because you’ll change your pricing more than once. Also note that UK rules around subscriptions are tightening under the Digital Markets, Competition and Consumers Act 2024, so check how they affect consumer-facing products.
7. Build in the operational basics
- Automated tests on the workflows that would hurt most if they broke, particularly billing and permissions.
- Error tracking and uptime monitoring from day one.
- Backups you’ve actually restored.
- Audit logs for sensitive actions, which larger customers will ask about.
- GDPR basics: a data processing agreement for customers, data export, deletion and a list of your sub-processors.
8. Launch early and learn
Onboard your first customers personally. Watch them use it. Every moment of confusion is cheap research. Focus on getting people to the first useful result quickly, and track whether they come back in week two and week four, since retention tells you whether you’ve built something that people need. Sign-ups alone won’t.
9. Plan for bigger customers later
Single sign-on, audit logs, security questionnaires and perhaps ISO 27001 or SOC 2 can open the door to larger deals. Don’t build them until someone wants to pay for them, but do keep the design open to them. Our SaaS development team can go through what this looks like for your product.