SaaS Product Development
From an idea to a product people pay for monthly
A SaaS business is a product plus the machinery around it — tenancy, billing, onboarding, and the instrumentation that tells you why people leave. We build all of it, aimed at your first paying customers rather than a launch announcement.
A senior engineer replies within 24 hours — not a sales rep.
What sinks SaaS products between launch and revenue
Multi-tenancy bolted on after the first enterprise deal
The product was built for one customer and tenancy was added later as a foreign key. Then a prospect asks where their data is isolated, whether an admin can be scoped to one workspace, and whether they can have their own SSO. Retrofitting that touches every query in the codebase, and it always lands during the deal you most want to close.
Billing that can't express what sales just sold
Stripe is wired up for a flat monthly plan. Then come annual contracts, seats added mid-cycle, a usage component, a discount for the design partner and a customer who insists on invoicing in arrears. Proration, dunning, failed-card recovery and plan changes are where SaaS engineering time quietly disappears.
Signups arrive and nothing happens
People create an account, look at an empty screen with no data in it, and never come back. Activation is a product problem — sample data, a first-run path to one real outcome, sensible defaults — and it's usually the last thing built, long after the acquisition spend has started.
You can see revenue but not the reasons behind it
MRR is visible in Stripe. What isn't visible is which accounts stopped using the feature that predicts renewal, which cohort activated and which didn't, or which customers are costing more in infrastructure than they pay. Without that, churn gets discovered at renewal, when it's already too late to act.
What we build into a SaaS platform from the start
The commodity parts of SaaS are well understood, and rebuilding them badly is a tax on your runway. We put the standard machinery in early and cheaply, so your engineering effort goes to the part that's actually your product.
Tenancy decided deliberately, in week one
Shared schema, schema-per-tenant or database-per-tenant is a business decision as much as a technical one — it follows from who your buyers are and what they'll demand about isolation. We pick with you, enforce it at the data-access layer rather than by developer discipline, and design so a large customer can be moved to dedicated infrastructure later without a rewrite.
Subscriptions, invoicing and the unhappy paths
Plans, seats, trials, upgrades and mid-cycle proration built on Stripe or a comparable provider, with webhook handling that survives retries and out-of-order events. Failed payments get a dunning sequence, not a silent loss. Entitlements are enforced server-side, so a plan change takes effect immediately and consistently.
Onboarding designed for the first ten minutes
Workspace creation, teammate invitations, role assignment, and a first-run experience that gets a new account to one genuinely useful outcome before it asks for anything. Empty states carry sample data and a next action rather than a shrug.
Product analytics and cost per account
Event instrumentation for activation, feature adoption and the usage signals that precede cancellation, wired to a dashboard you'll actually open. We also track infrastructure cost per tenant, because a heavy customer on a cheap plan is a pricing problem you want to find before it scales.
The stack we build on
Chosen to fit the problem — not because it's what we used last time.
Application stack
- TypeScript
- Node.js / NestJS
- Next.js
- React
- Python / Django
- Ruby on Rails
- Go
Billing, auth & tenancy
- Stripe Billing
- Paddle
- Auth0
- Clerk
- Keycloak
- SAML and OIDC SSO
- Row-level security in Postgres
Data & analytics
- PostgreSQL
- Redis
- ClickHouse
- Segment
- PostHog
- Metabase
Infrastructure
- AWS
- Google Cloud
- Kubernetes
- Terraform
- GitHub Actions
- Datadog
- Sentry
How we'll work together
Every stage ends with something in your hands — not a status update.
- 01
Define the smallest sellable product
We work backwards from the customer who'll pay first and cut everything that doesn't get them to value. Pricing model, tenancy model and the one workflow that justifies a subscription get decided here, because all three constrain the architecture.
You get: A scoped v1 feature set, a pricing and packaging model, a tenancy decision written down with its reasoning, and a fixed price for the build.
- 02
Build the platform foundation
Accounts, workspaces, roles and permissions, billing integration and the deployment pipeline. Unglamorous, and the thing that determines how fast every feature after it can be built.
You get: A deployed application skeleton with working signup, tenant isolation, live subscription billing in test mode, and CI/CD running to staging and production.
- 03
Ship the core product to real users
Two-week cycles building the workflow your customers pay for, released to design partners as it becomes usable. Their behaviour in the product, not their opinions in a call, drives what gets built next.
You get: A working product in the hands of design partners each sprint, with an instrumented funnel showing where accounts activate and where they stall.
- 04
Open the doors and watch the numbers
Public launch with monitoring, alerting, support tooling and an on-call path. Then the first weeks of real traffic, where activation drop-off and infrastructure cost per account tell you what to fix and what to price differently.
You get: The live production platform, a dashboard covering activation, retention and per-tenant cost, incident runbooks, and the repository in your accounts.
Where we've applied this
Healthcare
Clinic and practice platforms sold per location, where tenant isolation and audit logging are procurement requirements rather than nice-to-haves.
Logistics
Shipper and carrier portals where each customer needs their own users, rate cards and integrations without a separate deployment per account.
Retail
Merchant-facing tools billed on usage — orders processed, listings synced — which makes metering accuracy a revenue issue, not a reporting detail.
Finance
Back-office platforms sold to firms who'll ask for SSO, granular roles and an export of everything before they sign the first contract.
Education
Institution-wide platforms with annual purchasing cycles, seat-based licensing and administrators who need to manage cohorts without touching support.
Professional services
Vertical practice management products where the buyer is a small firm, self-serve signup has to work without a sales call, and onboarding is the whole sales process.
Clients we've built for
Real products, in production, with real users on them.
Questions buyers ask us
A focused first release usually reaches production in a few months, and design partners are typically using it well before that. The variable isn't engineering speed — it's how much you're willing to leave out of v1. The fastest projects we run are the ones where the founder has already decided who the first customer is and what single problem the product solves for them.
Use Stripe or a comparable provider. Almost nobody should build billing infrastructure, and the ones who eventually do have revenue that justifies it. What does need building is the layer between the provider and your product: entitlements, plan-change behaviour, usage metering and webhook handling that copes with duplicate and out-of-order events. That's where the bugs live, and it's where we spend the time.
It depends on your buyer. Selling self-serve to small teams, a shared schema with row-level security is efficient and simple to operate. Selling into regulated enterprises who'll audit you, a schema or database per tenant answers questions you'd otherwise argue about for months. We often start shared and design the escape hatch so a large customer can be lifted onto isolated infrastructure without touching application code.
Integrations and roles, mostly. The core workflow is usually the predictable part; what expands scope is every third-party system you must sync with, and permission models where different customers want different rules. Compliance requirements — SSO, audit trails, data residency — are the other big driver, and they're much cheaper designed in than added after your first enterprise prospect asks.
Yes to both. The repository, infrastructure and pipeline are yours from day one, in your accounts. If you hire an in-house team once you've raised or reached revenue, the build is documented and tested with that transition assumed. We'll onboard your first engineers ourselves if that helps.
That's the normal arrangement — a SaaS product is never finished, and the months after launch produce the most useful information you'll ever get about it. We run continuing sprints against what the usage data shows, handle infrastructure and on-call, and scale the team up or down as your roadmap and funding change. Some clients keep a full squad; others keep two engineers and a support agreement.
Tell us who your first paying customer is
Send us the product idea and who you think will buy it. A senior engineer replies within 24 hours with a view on scope, the tenancy and pricing decisions worth making early, and what a realistic first release looks like.