SaaS platforms
SaaS development, from first tenant to paying customers
Multi-tenant SaaS platforms engineered end to end: tenant isolation, subscription billing and plan limits, roles and permissions, onboarding, an admin console and a versioned API. Tenancy and billing decisions are written down with their trade-offs before any code, so the platform can grow without a rebuild.
- Typical timeline
- Several monthsTo a first paying-customer release after a discovery sprint
- How it’s quoted
- IndividuallyAfter a 30-minute call
- Who edits it
- Your teamThrough the admin console built alongside the product
- Stack
- TypeScript or .NETPostgreSQL with tenant isolation; serverless or managed services on AWS, Azure or Google Cloud
In your name Accounts and repositories, from day one Yours The code and documentation, under the signed agreement
On this page
Is it the right call?
When it’s the right call
- You are building a product that many organizations will sign up for and pay for
- Each customer needs its own data, users, roles and settings
- Billing, trials and plan limits have to be enforced by the product itself
- An existing product has outgrown a single-tenant build or a no-code prototype
When it isn’t
- One organization will use the software internally We’d suggest: A custom web app without multi-tenancy
- You have not yet confirmed that customers will pay for it We’d suggest: A clickable prototype and customer interviews first, which a discovery sprint can include
Sound like you? The first step is a 30-minute scoping call with the engineer who would lead the work.Request a scoping call
The smallest way to start
- Fixed scope, usually 2–3 weeks
Discovery sprint
Research into your users, systems and constraints, the architecture decisions written down, and a written plan and quote, yours to take to any team.
Start with a discovery sprint What the written plan covers
Standard equipment
What we usually hand over on a project like this. Your proposal lists exactly what’s included.
- TypeScript
- .NET
- PostgreSQL
- AWS
- Azure
- Google Cloud
- AWS Lambda
- Firebase
Product and architecture decisions
Tenancy model, billing approach and data boundaries written down, with the trade-offs.
Production platform
Sign-up, onboarding, billing, roles and the core product, deployed to your cloud account.
API and infrastructure
A documented, versioned API for integrations and partners, and the environments, releases and monitoring behind it.
Admin console
Tools for your team to manage tenants, plans, support cases and feature flags.
Automated quality gates
Tests, accessibility checks, performance budgets and tenant-isolation checks on every change.
Handover documentation
Runbooks, incident procedures and a codebase tour your next engineer can follow.
What we build
Subscription platforms for a specific industry, B2B tools with per-company workspaces, and marketplaces with roles on both sides. The parts most SaaS products eventually need, such as tenant isolation, plan limits, audit logs and usage metering, are designed in from the start rather than retrofitted under load.
When the product also needs a phone app, we build it against the same versioned API, so the web product and the iOS and Android apps share one set of decisions, one design system and one release process.
The API and infrastructure underneath
Most platforms eventually need a public API, for customers’ own systems, partners and integrations, so we design one from the start, documented and versioned, and set up the infrastructure in your own AWS, Azure or Google Cloud account (how we set up cloud infrastructure). The back end is chosen for the product, not from habit. That might be a conventional application server, serverless functions such as AWS Lambda or Google Cloud Functions, a managed platform such as Firebase, or a mix. We record the reasoning, and when it should be revisited as the platform grows.
Before the first line of code
Before writing code, we map the riskiest assumptions: who pays, what they pay for, and which integrations the product cannot live without. Those become written decisions and a scoped first release. The work happens in a short discovery sprint, and the scoped first release becomes the plan you are quoted against.
More in Custom software
Cloud & APIs
Infrastructure and APIs your software can rely on, in your own AWS, Azure or Google Cloud account, documented so anyone can run them.
Modernization
Existing .NET, PHP and JavaScript systems made safe to change again, one release at a time, planned to keep the system in use.
Questions about SaaS platforms
What should the first version of a SaaS product include?
The first version should include only what a customer needs to get value and pay: sign-up, the one core workflow, billing and basic roles. Everything else waits for evidence. A discovery sprint turns your feature list into a scoped first release, with the reason each item is in or out written down.
How long until a SaaS product can take its first paying customer?
A first paying-customer release usually takes several months after a discovery sprint, and the proposal sets the exact timeline once that release is scoped. Billing, the number of roles and the integrations the product can’t launch without drive most of it.
How do you keep one customer’s data separate from another’s?
We keep each customer’s data separate by design: every record belongs to a tenant, the database enforces that boundary with row-level security, and automated tests on every change check that one tenant can’t read another’s data. A customer that needs stronger separation can have a dedicated database.
Every build, any stack
One standard.
Performance
A performance budget is set before launch and enforced on every change.
Accessibility
Built to WCAG 2.2 AA and tested against it, with automated checks and manual keyboard and screen-reader passes on client builds.
Security
Least-privilege access, secrets kept out of code, dependencies monitored and security headers configured.
Handover
Accounts and repositories in your name from day one. The code and documentation are yours under the signed agreement, written so another team could take over.
Start a project
Tell us who will pay for it.
Who the customer is and the one workflow they’d pay for are enough to start. We reply within one business day, with questions or a time to talk.
Pittsburgh, PA · Since 2015 · First step: a 30-minute call