SaaS development for companies turning software into a product.

Sell the tool, service, or idea to many customers on one platform. The first release covers tenants and accounts, onboarding, billing through a provider, admin tools, and data isolation tested every time we ship.

Scope a SaaS product How the work runs

Who hires us for this

Founders with a product idea and a first customer, operating businesses that want to sell the tool they built for themselves, and software companies that need a second product or a new line built without pulling the team off the first. The product will have customers who are not you, and everything that implies.

Why now

A customer has asked to use the internal tool the business built for itself.
A service the company delivers by hand could be delivered by software.
The roadmap has a second product and the team is on the first.

What this covers

What SaaS development covers.

Tenant and account model

Companies, users, roles, and data separation designed for many customers from the first release.

Onboarding and billing

Sign-up, plans, trials, invoicing, and payment, integrated with a billing provider rather than built.

Admin and operations

The tools your team needs to run the product: tenants, usage, support, and configuration.

Security and isolation

Each customer sees only its own data, with authentication, access control, and audit designed in.

Monitoring and release

Errors, usage, and cost visible; releases on a cadence without downtime.

From MVP to product

A first release scoped to prove the product with real customers, on a foundation that becomes the product.

A decision, not a pitch

Internal tool, single-tenant, or multi-tenant?

The tenant model is the decision that is hardest to change later. This is how we make it.

Consideration	Internal tool	One deployment per customer	Multi-tenant
Fits when	Only your business uses it	A few large customers with strict isolation needs	Many customers on one product
Operations	One system to run	One system per customer to run and update	One system, tenants separated in the data
Cost per customer	Not applicable	High	Low once built
Our usual advice	Start here if the product is unproven	Rarely, and only for a specific reason	Most SaaS products, from the first release

One product, one release processmonitoring · billing · admin
Customer Ausers · roles · data · plan
Customer Busers · roles · data · plan
Customer Cusers · roles · data · plan

Each customer is isolated from the others.

Tenants share the product and nothing else. The model is decided before the first screen.

When companies call us

If this sounds like your business, here is where we start.

A customer wants to use the tool we built for ourselves

The internal tool made multi-tenant: accounts, isolation, onboarding, and billing, with the first customer on it.

A founder has a first customer and a prototype

A first release for that customer: the core loop, accounts, billing, monitoring, and a release process.

A software company needs a second product

Built as a bounded initiative alongside the team, to the company’s standards, and handed over.

A service could be delivered as software

The service’s workflow as a product, starting with the customers who already buy it.

How the work runs

Scoped in writing, built in releases, handed over.

01
Define the product and the first customers
The core loop, who pays for it, and what the first customers must be able to do.
02
Design the tenant model
Companies, users, roles, data separation, and the plans, before any screen.
03
Build the first release
The core loop, accounts, billing, admin, monitoring, and a release process, with real customers.
04
Onboard and measure
The first customers onboarded, usage and errors watched, the next release scoped from what they did.
05
Hand over
Documentation and a runbook, so your team can run the product day to day.

Deliverables

What you receive.

ScopeAgreed

First release · version 1.2Scope and acceptance

Includes: The core workflow, roles and permissions, and the first integration
Left for later: Reporting and the second integration
Acceptance: Criteria agreed with your team
Price: Fixed before the build begins
Start date: Agreed in writing

Approved by operations Approved by finance

RunbookHanded over

Operations · version 1.0Running the system

01Deploy a releasePipeline
02Roll back a releaseTested
03Restore from backupTested
04Alerts and who respondsCurrent
05Access and secretsBy role

Written scope
What the first release includes, what it leaves for later, the integration decisions, the acceptance criteria, and the price, agreed before development begins.
Release notes
What changed in each release, what was tested, what the security review covered, and how to roll it back.
Documentation and runbooks
How the system is built, how to run it day to day, and what to do when something fails.
Training and handover
Sessions with the people who will use and run the system, and a handover checklist your team signs off on.

Every release ships with tests, a security review, and documentation, so your team can run what we build.

Your first release

What the first release could include.

The scope is written and agreed before development starts. This is the shape it usually takes.

In the first release

The core loop for the first customers, end to end
Tenants, accounts, roles, and data isolation
Sign-up, plans, and billing through a provider
Admin tools for your team
Monitoring, backups, security review, and a release process

Usually later

Self-service onboarding and trials
Integrations customers ask for
Usage-based plans and reporting

Systems it may connect

Built to work with what you already run.

Billing: Stripe and similar
Identity providers and single sign-on
Email and notification services
Analytics and product instrumentation
Customer support tools
Cloud hosting and delivery pipeline

How we build it

TypeScript, React and Next.js, Node.js, and PostgreSQL by default, with tenant isolation at the data layer, deployed with a documented release process. For an existing product we work in its stack.

Fleet maintenance shop

Fleet customers sign up for the shop’s inspection app, each with separate data and billing.

A fleet maintenance shop sometimes builds an inspection app for its technicians and then finds that the fleets it serves want to use it too. Turning that app into a product means an account per fleet, roles for fleet managers and drivers, data isolation tested with every release, sign-up and plans with billing through a provider, and admin tools for the shop. Existing customers are a natural first group, since they know the app. Self-service trials and telematics integrations can follow once the shop decides to sell beyond its customer base.

Where this shows up

Industries where we do this work.

Examples, not a closed list. We take substantial projects from independent businesses in other industries too.

Software companies

Ship the integration customers keep asking for, the mobile client, or the modernization your roadmap has no room for, while your engineers stay on the current release.

Technology-enabled businesses

The internal tools and customer-facing apps your service runs on, built by a senior team before you are ready to hire engineers.

Private equity portfolio companies

Software across the hold period, with a portfolio assessment for the fund and a delivery path for each company.

Another industry entirely

Describe the workflow and the systems around it. Fit depends on the work and the stakes, not the sector.

In plain terms

What is SaaS development?

SaaS development builds a software product that many customers use over the internet on a subscription: the tenant and account model, onboarding, billing, admin tools, security, monitoring, and the release process, as well as the product itself. It is product engineering with customers who are not you.

We build the first release to be the product, not a prototype to throw away, and we hand it over documented, ready for your team to run.

Questions

Questions about SaaS development.

What buyers ask before a project starts, answered plainly.

Should we start multi-tenant?

Usually yes, from the first release, because the tenant model is the hardest thing to change later. The exception is an unproven idea, which starts as an MVP for one customer on the same foundation.

Do you build billing?

No. We integrate a billing provider for plans, invoices, and payment, and build the product’s side: what a plan allows and what happens when it changes.

How is customer data kept separate?

Through isolation at the data layer, authentication and access control per tenant, and tests in every release that prove one customer cannot see another’s data.

What about security questionnaires from customers?

The first release includes the controls most questionnaires ask about: access control, backups, monitoring, audit, and documentation. Certifications are a separate decision.

Can our existing tool become the product?

Often. The assessment says what has to change, usually the tenant model and the admin tools, and the first release makes those changes with the first customer on it.

Who runs the product afterwards?

Your team runs it, with documentation, monitoring, and a runbook, and we can carry the roadmap forward with you, release by release.

Scope a SaaS product.

Tell us about the work and the systems around it.
We’ll come back with a written scope for a first release.