A SaaS version 1 with multi-tenant accounts, Stripe Billing, onboarding and an admin console typically takes 16 to 24 weeks, with working software demoed every two weeks. A narrower SaaS MVP for the first paying customers can go live in 8 to 12 weeks. We build enterprise readiness in from the start (audit logs, SAML single sign-on, UK data hosting), and your company owns the code, the cloud account and every piece of IP.
Three kinds of SaaS client
Most SaaS projects we see come from one of three places, and each needs a slightly different approach.
- Founders with deep industry knowledge. A former practice manager who knows exactly what dental clinics hate about their software, or a logistics director who has watched hauliers run empty return legs for years. The domain insight is the asset. We supply the product engineering.
- Businesses productising an internal tool. You built something to run your own operation and competitors keep asking to use it. The code that works for one company needs real multi-tenancy, billing and onboarding before it can serve fifty.
- Software companies short of capacity. You have a product and a team, and need a module, a rebuild or a second team for a fixed period. See our dedicated development team option for that.
If you have not yet proved anyone will pay, start smaller. Our MVP development service is built for that stage, and the code carries forward into version 1.
When building a SaaS product is a mistake
SaaS looks attractive because of recurring revenue, but it is a demanding business: you are signing up to support, uptime, security reviews and a roadmap for as long as you have customers. A few situations where we advise against building:
- A white-label product already exists. In many niches, booking, membership, e-learning and CRM among them, you can license and rebrand a platform and put your energy into selling.
- It is really a service with software inside. If customers mainly come for your expertise, a client portal on top of your service may serve them better than a self-serve product.
- The market is a handful of large buyers. Five enterprise customers is a bespoke software contract, not a SaaS business. Build and contract for it that way.
- No plan beyond launch. If the team stops at go-live, the product will stall the moment the first customers ask for changes. A SaaS needs a roadmap and people to deliver it for at least the first year.
Multi-tenancy: the decision that is hard to reverse
Multi-tenancy is how one running system keeps each customer's data separate. It is the most important architecture choice in SaaS development, because changing it after launch is close to a rewrite.
| Model | How it works | Strengths | Watch out for |
|---|---|---|---|
| Shared database, tenant column | Every row carries a tenant ID, enforced by PostgreSQL row level security | Lightest to operate, simple upgrades, scales to thousands of tenants | Needs disciplined testing so one tenant can never see another's rows |
| Schema per tenant | One database, a separate schema for each customer | Clearer separation, easier per-customer export | Migrations must run across every schema; awkward past a few hundred tenants |
| Database per tenant | Each customer gets their own database, optionally in their chosen region | Strongest isolation, data residency, easy to answer enterprise questions | More to operate, monitor and back up for each customer |
Our usual answer is a shared database with row level security for most customers, plus the option to give an enterprise customer a dedicated database later. We design the code so that switch is a configuration change, not a rebuild. Tenant isolation gets its own automated tests that try to read across tenants, because that is the bug that ends SaaS companies.
Subscriptions with Stripe, GoCardless or Paddle
Subscription handling looks simple in the pitch deck and turns out to be one of the larger pieces of work. A real SaaS needs plans, free trials, upgrades and downgrades mid-month with proration, seat or usage-based charges, failed payment retries, tax-compliant documents and a customer portal for card changes.
- Stripe Billing is our default. It handles subscriptions, proration, documents and dunning, and has well documented APIs and webhooks we can test thoroughly.
- GoCardless makes sense alongside Stripe when UK business customers prefer Direct Debit, which many finance teams do for monthly software.
- Paddle or another merchant of record sells to your customers on your behalf and handles sales tax worldwide, which can save a small team a great deal of admin if you sell to consumers in many countries.
We settle the shape of your plans in discovery, because seat-based, tiered and usage-based models each need different data recorded from the first day. Changing the model later is possible but far harder than getting the shape right first.
Onboarding is where SaaS products win or lose
Most trial users decide within the first session whether a product is worth their time. If sign-up leads to an empty dashboard and a settings page, many never come back. We treat onboarding as a feature with its own sprint, not an afterthought.
In practice that means: sign-up with Google or Microsoft as well as email, a short setup that asks only what is needed to show value, sample data so the product looks alive, invites so the user can bring in colleagues, and a sequence of emails triggered by what the user has or has not done. We wire up product analytics with an EU-hosted tool so you can see where people drop out of the funnel.
The measure we design for is time to first value: the minutes between sign-up and the moment a user gets something useful out of the product. Cutting that is usually worth more than any new feature.
Answering the enterprise security questionnaire
The first time a larger UK customer is interested, their procurement team will send a security questionnaire, often 100 to 300 questions long. Typical questions: do you hold SOC 2 or ISO 27001, where is data stored, do you support SAML single sign-on, can we see your penetration test report, who are your sub-processors, how do you handle a breach.
Certifications such as ISO 27001, Cyber Essentials and SOC 2 (an American audit standard that US buyers ask for) are awarded to your company and its processes, not to a codebase. We do not hold them ourselves and cannot hand them to you. What we can do is build the product so that achieving them is straightforward:
- Audit logs of every sign-in, permission change and data export.
- SAML and OpenID Connect single sign-on with Microsoft Entra ID, Okta and Google Workspace.
- Role-based access, enforced multi-factor authentication for admins, and session controls.
- Infrastructure defined as code in your cloud account, with encrypted storage and tested backups.
- A sub-processor list, a data processing agreement template for your customers, and a documented incident process.
For many UK B2B products, Cyber Essentials is a sensible first certificate and is required for some government contracts. Our security page explains how we work on the build side.
A 22 week SaaS build, sprint by sprint
- Weeks 1 to 3: discovery. Personas, plan structure, tenancy design, subscription rules, the integrations customers will expect, and a written specification for version 1.
- Weeks 3 to 6: design. Product design and a component library, so new screens later are quick and consistent.
- Weeks 6 to 8, sprint one: sign-up, tenants, teams, roles and the data model.
- Weeks 8 to 14, sprints two to four: the core product features, demoed every two weeks on a test link you can show to prospects.
- Weeks 14 to 16, sprint five: Stripe Billing, trials and the customer self-service portal.
- Weeks 16 to 18, sprint six: onboarding, lifecycle emails, admin console and usage metrics.
- Weeks 18 to 21: beta. Ten to twenty friendly customers, a security scan and an external penetration test if you are selling to larger firms.
- Week 22: launch, then a 30 day warranty.
The general method behind every sprint is on how we work.
Owning your product outright
For a SaaS business, the code is not a supporting tool. It is most of what an acquirer or investor is buying. So the ownership terms matter more here than on any other kind of project.
The contract assigns copyright and all IP in the code we write to your company, with no licence back to us and no reuse of your product logic for anyone else. The repository, AWS or Azure account, Stripe account, domain and transactional email service are registered to your company from the first week. Third-party and open source components are listed with their licences, so due diligence does not turn up a surprise.
If we disappeared, you would still have the code, the infrastructure definitions, the deployment pipeline and the documentation, and any competent team could carry on. Our guide on what happens if your developer goes bust lists what to demand from any supplier.
Uptime, scaling and shipping after launch
Once customers depend on your product, reliability becomes a feature. We set up uptime checks, error tracking and alerting before launch, with automated deployments that can be rolled back in minutes if a release misbehaves. Databases are backed up nightly with point-in-time recovery, and restores are tested rather than assumed.
Scaling is planned, not improvised. Per-tenant usage metrics in the admin console show which customers drive load, and the hosting is set up to add capacity without code changes. Most SaaS products never need anything exotic: well indexed PostgreSQL and sensible caching carry a long way.
Development rarely stops at launch. Most of our SaaS clients move to a regular monthly allocation of sprint days, so the product keeps shipping every two weeks. Plans run on 30 days notice, and when you hire your own engineers we hand over properly rather than holding on.