The features are the easy part
A SaaS product is an application plus a business model, and the business model is where the engineering gets interesting. Tenancy, billing, trials, plan limits, provisioning, churn instrumentation — none of it appears in the pitch deck, and all of it is load-bearing.
You might be here because
Situations we are brought in for
- You are pre-launch and the tenancy decision is about to become permanent.
- Billing was bolted on and now nobody can answer what a customer is actually owed.
- Every new enterprise customer needs a code change to onboard.
- The product works, and you cannot tell which accounts are about to churn.
What you get
Concrete deliverables, not a retainer with a hope attached
Tenancy architecture
Shared schema, schema per tenant, or database per tenant — chosen against your isolation, compliance and cost requirements, and documented so the reasoning stays visible long after the decision. This is the choice that is most expensive to reverse.
Billing and entitlements
Plans, seats, usage metering, proration, trials, dunning and the invoice reconciliation nobody scopes. Entitlement checks live in one place rather than scattered through the codebase as plan-name comparisons.
Self-serve onboarding
Signup, provisioning, invites, roles and SSO, built so that adding a customer is a database row rather than a deployment.
Product instrumentation
Activation, usage and retention events defined and wired at build time. Retrofitting analytics after launch means the first six months of data is missing.
How it works
Four phases, each with an exit you control
- 01
Model
We start with the commercial model — how you charge, who administers an account, what an enterprise buyer will demand at contract stage — because that determines the data model, not the other way round.
- 02
Foundation
Tenancy, authentication, authorization and billing built first, as a working thin slice. These are the parts that are painful to change once real customers exist.
- 03
Product
Feature work in two-week cycles on top of a foundation that no longer needs revisiting every sprint.
- 04
Scale
Load characteristics, noisy-neighbour isolation, per-tenant cost visibility and the operational tooling your support team needs to answer customer questions without an engineer.
Tools we reach for
Chosen per problem, not per fashion
This is what we use most for saas development. If your team is already productive in something else, we work in that instead — familiarity in your team beats preference in ours.
- TypeScript
- SvelteKit
- React
- Node.js
- PostgreSQL
- Redis
- Stripe
- Docker
Where this usually starts
Build Cycle
Most common
Build Cycle
Getting a defined product or feature set shipped to production
A dedicated senior team working in two-week cycles against an agreed outcome. You see working software at the end of every cycle and can change direction between them.
- Typical duration
- From 6 weeks
- Commitment
- Rolling, cycle by cycle
Includes
- A senior team sized to the work
- Two-week cycles with a working demo at the end of each
- Direct access to the engineers building it — no account layer
- Your repositories, your CI, your review process
- Production readiness and handover built into the plan
You keep
- Working software in production
- Test suite and CI pipeline
- Architecture and operations documentation
- Handover sessions with your team
Fee agreed after scoping. No commitment to that conversation.
Common questions
How long does it take to build a SaaS MVP?
For a focused product with one core workflow, self-serve signup and subscription billing, a realistic range is three to five months to something real customers pay for. Anything quoted at six weeks is either much smaller than described or is deferring the tenancy and billing work into a bill that arrives later.
Which multi-tenant model should we use?
Shared schema with a tenant column handles the large majority of products and is the cheapest to operate. Database per tenant is worth the operational overhead when you have hard isolation requirements, per-customer data residency, or enterprise buyers who will audit you. The wrong answer is choosing database-per-tenant early because it sounds safer.
Can you take over a SaaS product someone else built?
Frequently. That usually starts as a technical audit: an independent read of the codebase, infrastructure and the parts of the system nobody has looked at since the original team left, with findings ranked by risk before anyone commits to a rebuild.
Other services
Product engineering
Ship the product your roadmap keeps promising — designed, built and maintained.
Platform & infrastructure
Make deploys boring, incidents rare, and cloud spend explainable.
Legacy modernisation
Untangle the system nobody fully understands — without stopping the business.
AI & applied ML
Put language models into production without betting the product on a demo.
Custom software
For the process no product on the market actually fits — built once, properly.
Web applications
Serious applications in the browser — dashboards, editors, real-time tools that stay fast with real data.
API development
Interfaces other engineers have to live with — versioned, documented and hard to misuse.
Mobile apps
Apps that work on a bad connection, clear store review, and can be shipped weekly.
Next step
Think this is your problem?
Send us the shape of it. We will tell you whether it is a fit, what we would do first, and roughly what that takes.