SaaS development
SaaS development: a platform many customers can share safely.
We build SaaS products where each customer's data is kept apart by the database itself, and billing and permissions work from the first release. A senior engineer leads, and the scope and price are fixed before we start.
Photography is illustrative.
- We build
- New SaaS products, and existing software turned into multi-tenant SaaS
- Foundations
- Organizations, roles, tenant isolation in the database, billing, environments
- First step
- A short, priced discovery that ends in a fixed quote
- You own
- The code and the customer data, in your accounts, from the first day
What we do
SaaS development services, foundations to features.
A SaaS product is software many customers sign up for and share, each seeing only their own data. The features differ from product to product. The foundations underneath them are much the same, and they are where SaaS products most often go wrong.
- Multi-tenancy. Every customer is an organization with its own data, users and settings, kept apart by rules in the database, with tests that try to cross the boundary.
- Accounts, roles and permissions. Sign-up, invitations, owners, admins and members, and the rule for who may see and change what, written once and enforced everywhere.
- Subscription billing. Plans, trials, upgrades, failed payments and cancellations, with your payment provider's events handled reliably so access always matches what the customer has paid for.
- Admin and support tools. The screens your own team needs to help a customer without reaching into the database by hand, with every action recorded.
- Integrations and APIs. Webhooks, background jobs and a public API if your customers need one, with retries and failure cases designed in.
- Operations. Separate environments, migrations that run the same way every time, monitoring, backups and rollback.
The decisions that matter
What is expensive to change once customers are on it.
Some choices are cheap to revisit: a screen layout, a report, an onboarding email. Others become very expensive once real customers and their data are on the platform. These we settle in discovery and build properly in the first release:
- The tenancy model. How customers are separated, and whether any customer will ever need its own database.
- The permission model. Roles inside each customer, and anything your own staff can see across customers.
- How billing grants access. One place in the code that decides what a customer's plan allows, rather than checks scattered across the product.
- The data model. Tables shaped around your business, so new features extend it rather than work around it.
Everything else can start simple and grow with demand. We will tell you which features we would leave for the second release, and why.
How it works
Discovery, foundations, then the product in reviewed steps.
Every engagement is led by a senior engineer and runs through the same reviewed engineering process we use on our own software, including AI-assisted work under human review.
-
Discovery
A short, priced discovery: who your customers are, who inside each customer uses the product and with what permissions, how you will charge, and which systems it must connect to. We settle the tenancy model here, because it is the decision that is hardest to change later.
You get A written plan with the data model, the tenancy and permission rules, a schedule and a fixed quote.
-
Foundations first
Sign-up and sign-in, organizations and roles, tenant isolation in the database, billing, and separate development, staging and production environments, with automated tests on the isolation rules before any feature is built on top of them.
-
Features in small, reviewed steps
The product itself, built in increments you can try as they land. Every change is reviewed before it merges and tested automatically before it deploys, in your repository, with access to the code and the pipeline from the first day.
-
Launch and run
Monitoring, error alerts, backups that have been restored at least once, and a deploy that can be rolled back. Migrations run the same way every time, so a schema change does not become an outage.
You get A live SaaS product, and the notes to run and change it.
Timeline and pricing
How long a SaaS build takes and how we price it.
New software is quoted, not listed. Defined work gets a fixed price and fixed scope. When the product is not defined yet, the discovery is bounded and priced up front too, and it ends with a schedule and a fixed quote for the build.
What moves the price and the date: the number of customer types and roles, the plans and billing rules, the integrations, whether existing data or an existing single-customer app has to be brought across, and any regulatory constraints on the data your customers will store. Our published prices, for checking, fixing and looking after an app that already exists, are on the pricing page.
Proof
Multi-tenant software the founding team built and runs.
The founding team built and runs a production multi-tenant telehealth platform in which many independent clinical organizations share one system, and no organization can see another's records: isolation is enforced in the database with row-level security and verified by automated tests. Across the systems the founding team built and runs:
- 20,900+ automated tests across the systems the founding team built and runs
- 16,800+ CI runs automated builds and test runs on GitHub Actions
- 2,500+ database migrations in one production healthcare platform
- 370+ server functions in the same platform, in production
Counted from the repositories and CI history of the systems the founding team built and runs, 22 Sep 2026; each figure rounded down. How we counted
Questions buyers ask
Before you build a SaaS product.
How much does it cost to build a SaaS platform?
A SaaS build is quoted, not listed, because the cost is set by its scope: the number of user roles, the integrations, how billing works and how much of the first version can wait. The discovery has a fixed price agreed before it starts and ends with a fixed quote for the build. We do not bill hourly on work nobody has sized. Our published prices.
How long does it take to build a SaaS product?
The plan from discovery gives the schedule, item by item. The foundations (accounts, organizations, roles, isolation and billing) take roughly the same effort for most products; what varies is the product on top. Launching with one plan and one customer type, then adding more, is usually the fastest route to paying customers.
How do you keep one customer's data away from another's?
With rules in the database itself, not only checks in the application code. Every table that holds customer data carries the customer it belongs to, and the database refuses to return rows from another customer even if a bug in the application asks for them. Automated tests try to cross the boundary on every change. Why we design access rules first.
Single database or a database per customer?
Most SaaS products are best served by one shared database with isolation enforced in it: cheaper to run, simpler to migrate and easier to report across. A separate database per customer makes sense when contracts or regulation require it, or when a few customers are very large. We will recommend one, with the reason, in the discovery.
Can you take an existing app and turn it into a multi-tenant SaaS?
Yes, and it is common: software built for one company that other companies now want to buy. The work is adding the customer boundary to every table, query and file store, with tests that prove it holds, then adding billing and self-service sign-up. We do it in steps, so the existing customer keeps working throughout.
Can you add AI features to our SaaS?
Yes. In a multi-tenant product, AI features need the same isolation as everything else: one customer's data must never reach another customer's prompt or answer. We design for that, plus cost limits per customer and a way to measure whether the AI is doing its job. AI app development.
Who owns the code and the customer data?
You do. The code lives in your repository and your cloud accounts from the first day, and your customers' data lives in your database, not ours. Ownership of what we write for you is set out in the agreement before any work starts.
Tell us about the SaaS you want to build.
Who your customers are, how you plan to charge, what exists today, and your timeline. An engineer reads it.
Next sheet · A‑070