SaaS Development
Multi-Tenant SaaS Development
A SaaS product needs tenancy, billing and user permissions in place before it can take its first subscription. Our SaaS development work covers all of that for clients, using the same approach we take with the multi-tenant products we run ourselves.
Get a project quote →Tested on our own SaaS products
TenantWise, FindContracts and ChronoWise are subscription products we built and still run ourselves. Running them day to day shows us what churn looks like and how much support each new feature brings in, as well as what a failed payment costs and where people give up during onboarding.
Most of the problems you're likely to hit with subscription software are ones we've already met on our own products, and we build the answers into your project from the start.
Choosing a tenancy model at the start
How you keep one customer's data away from another's is the most expensive decision in a SaaS build and the hardest to change once you're up and running. The realistic options are a shared schema with row-level isolation, a schema per tenant or a database per tenant. Each one costs and scales differently, and some make a security questionnaire much easier to answer than others.
We base the choice on who your customers are. The number you expect and their size both matter, as do how regulated your market is and what those customers are likely to ask of you in two years' time.
Billing, including the parts that go wrong
Charging for plans and trials looks simple until a customer switches plan mid-cycle and their card is declined, at which point nobody can agree what they owe.
We build billing on Stripe and deal with proration, failed-payment recovery and VAT invoicing from the first release. Mistakes in this area cost you revenue and customer goodwill at the same time.
An MVP that tests whether people will pay
The first release is there to find out whether people will pay, so we keep the scope tight and will tell you when a feature you consider essential could wait.
The tenancy, authentication and billing underneath are built to carry a much larger customer base, and a successful MVP won't need rebuilding before it can grow.
How a project runs
Shape
We work out who pays, what they pay for and the smallest version of the product that proves it.
Foundations
We set up tenancy, authentication, roles and billing on your cloud infrastructure before any feature work begins.
Build
We work in two-week sprints and deploy each one to a staging site you can log into and use.
Launch & iterate
We put the product live and then plan the next releases around how customers use it.
The technology we build on
Product
- Next.js
- React
- TypeScript
- React Native companion apps
Platform
- Node.js APIs
- PostgreSQL
- Stripe billing
- SSO & role-based access
Operations
- AWS
- Microsoft Azure
- Monitoring & alerting
- Automated backups
Frequently asked questions
What does it take to launch a SaaS product?
Beyond the feature people are paying for, you need accounts and sign-in along with onboarding that gets a new customer to something useful quickly. Your own team will want an admin area, and you'll need monitoring that tells you when something breaks. We build all of this alongside the core product so it's ready on launch day.
How should I separate customer data in a multi-tenant SaaS?
A shared schema with strict row-level isolation suits a large number of smaller customers and is the cheapest to run. A database per tenant suits fewer, larger customers in regulated markets who want their data kept physically apart, though it costs more to host and maintain.
Can you build an MVP first and scale it later?
That's what we recommend for most new products. We keep the MVP's feature list short and spend the time on tenancy, authentication and deployment, since those are the parts that are expensive to replace once customers depend on them.
Do you handle subscriptions and payments?
Yes, normally through Stripe. Alongside flat monthly plans we can set up per-seat or usage-based pricing, and Stripe stores the card details so they never touch your own servers.
Will we own the product and the code?
You will. The IP transfers to you and the code lives in your own repository, while the infrastructure runs in your cloud accounts. You're free to move the product to another supplier whenever you want.
Building a software product?
Tell us what you're planning and we'll set out what it takes to reach your first paying customer, along with what can wait until after that.
Tell us about your project