Build · Pillar 01
SaaS products built to be sold, supported and scaled.
Turning internal know-how into a commercial product is a different discipline from building a system for yourself. The hard parts are tenancy, billing, onboarding and support — and they are the parts most first attempts skip.
What does SaaS product development involve?
SaaS product development is building software that many separate customers use from one shared deployment, each seeing only their own data. Beyond the features themselves it requires tenancy isolation, subscription billing, self-service onboarding, usage metering and internal admin tooling — the commercial machinery that turns an application into a product someone can buy without speaking to you.
- One deployment, many isolated tenants, no per-customer codebase.
- Billing, trials, upgrades and failed payments handled automatically.
- Support tooling so your team can fix a customer issue without a developer.
Why it matters
The features are rarely what sinks a SaaS build.
Most stalled SaaS products we are asked to rescue work fine for one customer. They fail at the fifth, because tenancy was added as a filter rather than designed in, because every new customer needs a developer to set up, or because nobody built the admin screens support needs and so every query becomes an engineering ticket.
The commercial machinery is the product. A SaaS business is a system for acquiring, onboarding, billing and retaining customers with very little human cost per customer. If any of those four needs a person, the margin that makes SaaS worth doing disappears.
What investors and buyers check
The commercial machinery
Whether you are raising, selling or just trying to hold a gross margin, these are the things that get examined. They are architectural, so they are decided early whether you decide them or not:
- Adding a customer requires a developer, a migration or a config file.
- Tenant separation relies on remembering a WHERE clause.
- Billing is invoiced manually from a spreadsheet of who is on what.
- Support cannot see what a customer sees without the database.
- There is no way to know which features anyone actually uses.
- A customer-specific request gets solved by forking the code.
Scope
What building a SaaS product covers.
A first release needs all six. The temptation is always to defer billing and admin tooling, and it is always the wrong call.
-
Multi-tenant architecture
Tenant isolation enforced at the data layer, not by application convention, with a documented decision on shared versus separate schemas and why.
-
Subscription billing
Plans, trials, proration, upgrades, downgrades, failed-payment dunning and VAT handling, wired to Stripe or your payment provider rather than reinvented.
-
Self-service onboarding
Sign up, create a tenant, invite colleagues, import data and reach first value without a human in the loop. This is the single biggest lever on your cost per customer.
-
Internal admin & support tooling
Impersonation, plan changes, usage inspection and audit, so support resolves a ticket in minutes without touching production data by hand.
-
Usage metering & product analytics
What each tenant actually uses, measured per feature, which is what drives both your pricing model and your roadmap.
-
Security & compliance posture
SSO, audit logs, data residency, backup and retention policy, and the documentation an enterprise prospect’s security review will ask for.
Deliverables
What a first release gives you.
The goal of release one is not feature completeness. It is a product one real customer can buy, use and be billed for without your involvement.
-
A product that onboards itself
A new tenant can sign up, configure and reach first value unaided. Every hour of manual onboarding you remove is margin you keep at every future customer.
-
Revenue that collects itself
Subscriptions, trials, upgrades, proration and failed payments handled by the system. Recovering a failed card automatically is usually worth more than the next feature.
-
Support that does not escalate to engineering
Admin tooling that lets a support person see what the customer sees and fix the common cases. The alternative is a development team permanently on interrupt.
-
Evidence for the next conversation
Usage and retention data per tenant and per feature — what an investor, an acquirer or your own board will ask for, and what tells you where to build next.
Is this the right answer?
When saas products is worth doing — and when it is not.
We would rather lose a project at this stage than six weeks in. If the right-hand column describes you, say so and we will tell you what we would do instead.
Worth doing when
- You already run internal tooling your competitors would pay for.
- You can name the single job the product does better than a spreadsheet.
- You have, or can get, five businesses who say they would pay for it.
- You intend to sell it, not just use it.
Probably not when
- The idea has not been validated with anyone outside the business.
- You want every prospect’s request configurable — that is consultancy, not SaaS.
- There is no budget beyond a first release and no plan to raise or earn one.
- The real need is one system for your own business, which is cheaper to build.
How we deliver
How a SaaS product gets to market.
Sequenced so that the thing you can sell arrives before the thing that is nice to have.
-
Phase one
Shape the product
Who exactly buys it, what they will pay, which single job it does better than the spreadsheet it replaces. We will push back hard here, because a vague answer makes the next three phases guesswork.
-
Phase two
Tenancy & the core job
Multi-tenant foundations plus the one workflow the product is bought for. Nothing else. This is what goes in front of design partners.
-
Phase three
Commercial machinery
Billing, onboarding, admin tooling and metering. The release where the product stops needing you in order to be sold.
-
Phase four
Launch & iterate on evidence
Go live with real customers, instrument everything, and let usage decide the roadmap rather than the loudest prospect.
What you receive
The things that actually land.
Artefacts, not adjectives. Everything below is listed in the scope document before a phase starts, so “done” is a defined state rather than an opinion.
-
A product definition
Who buys it, what they pay, which job it does better than the alternative. Short, written and agreed before anything is built.
-
A multi-tenant platform
Tenant isolation enforced at the data layer with the shared-versus-separate schema decision documented and justified.
-
Working subscription billing
Plans, trials, proration, upgrades, failed-payment dunning and VAT, wired to Stripe in your own account.
-
Self-service onboarding
Sign up, create a tenant, invite colleagues and reach first value with no human in the loop. The biggest single lever on your cost per customer.
-
Internal admin tooling
Impersonation, plan changes, usage inspection and audit, so support resolves a ticket without a developer touching production.
-
Usage and retention instrumentation
What each tenant uses, per feature. What an investor, an acquirer or your own board will ask for first.
Golden Triangle
SaaS out of the Midlands.
A large share of the SaaS products we scope here are vertical — built by an operator who knows one industry extremely well. That is a strong position.
- Vertical SaaS Operator-founded Logistics, manufacturing and construction businesses in this corridor often already run internal tooling their competitors would buy. Productising it is a shorter route to revenue than inventing a category.
- Industry proximity Design partners nearby Having your first ten customers within an hour’s drive is a genuine advantage. Feedback arrives in person and in detail rather than through a support form.
- Capital efficiency Build, then raise Midlands SaaS tends to be built from revenue rather than a seed round, which makes the order of work matter. We sequence for a paying customer, not a demo.
We work with founders and corporate innovation teams across Birmingham, Nottingham, Leicester, Derby, Coventry and Northampton, including businesses spinning an internal system out as a separate product company.
Technology
SaaS technology.
Managed services wherever they exist. At this stage every hour spent operating infrastructure is an hour not spent finding customers.
- TypeScript
- Laravel
- PostgreSQL
- Redis
- Stripe Billing
- SSO / SAML
- AWS
- Azure
- Product analytics
- CI/CD pipelines
Where we deliver this
SaaS Products across the Golden Triangle.
35 locations, each with a page written for it — the sectors it is actually built on, and what that means for this work. See all areas we serve.
Northamptonshire 10
Warwickshire 5
West Midlands 5
Buckinghamshire 4
Leicestershire 4
Staffordshire 4
Derbyshire 1
Greater London 1
Nottinghamshire 1
Questions
Building a SaaS product, answered plainly.
Mostly asked by founders and by businesses productising something internal.
How much does it cost to build a SaaS product?
A credible first release — multi-tenant, billed, self-onboarding, with one workflow done properly — is typically a five to low six-figure build. GTX Digital phases it so that the money is committed against a written scope at each stage, and so that a sellable product exists before the budget is exhausted.
How long before we can charge a customer?
Four to seven months is realistic for a product that one real customer can buy and use unaided, assuming the first phase answers who buys it and why. Design partners can usually be using it well before that, which is where the most valuable feedback comes from.
Should we build multi-tenant or one instance per customer?
Multi-tenant, in almost every case. Separate instances feel safer and then quietly multiply your deployment, support and upgrade cost by the number of customers. The exceptions are genuine data-residency or regulatory requirements, and we design for those explicitly rather than by accident.
Can you turn our internal system into a SaaS product?
Often, and it is a strong starting point because the domain logic is already proven. The work is in retrofitting tenancy, extracting customer-specific assumptions, adding billing and onboarding, and deciding what deliberately will not be configurable. We assess feasibility honestly in discovery — sometimes a rewrite of the core is cheaper than the retrofit.
Do we need to build our own billing?
No, and you should not. Stripe Billing or an equivalent handles plans, proration, tax and dunning far better than a custom implementation, and the integration is a fraction of the cost. What we build is the mapping between your plans and your product’s entitlements, which is the part that genuinely is yours.
Who owns the product and the code?
You do, completely. The repository, the cloud accounts, the Stripe account and the intellectual property are yours from the start. We are a development partner, not a co-founder, and nothing in the arrangement makes us difficult to replace.
How do we price the product?
We will help you reason about it but it is a commercial decision, not a technical one. What we build in is the instrumentation to answer it with evidence: usage per tenant and per feature, so you can see what people actually value rather than what they said in a sales call. Pricing changed on evidence beats pricing guessed once.
What if a big prospect wants something custom?
This is the decision that determines whether you have a product or an agency. The answer is usually a configuration option if several customers would use it, and a polite no if only one would. We build the configuration layer so that distinction is cheap to act on, but the discipline has to come from you.
Do we need to be technical to run it?
Not day to day. The admin tooling is built so support and operations can do their jobs without engineering, and deployment is automated. You will eventually want technical capability in house or on retainer, because a product that is selling is a product that needs changing, but it is not a condition of launching.
What does it cost to run once it is live?
For an early-stage product, typically hundreds rather than thousands of pounds a month in infrastructure, plus payment processing fees. We use managed services deliberately: at this stage every hour spent operating infrastructure is an hour not spent finding customers, and the cost difference is trivial next to that.
Related services
Usually scoped with this.
-
Build
Web Platforms
Logged-in platforms that carry real transactions, not brochure websites.
Explore -
Connect
API Development
APIs and integrations so data is entered once and moves on its own.
Explore -
Automate
Dashboards & Reporting
Reporting that answers a decision, not dashboards nobody opens twice.
Explore
Next step
Bring the product idea and the customer list.
Even a list of five businesses that have said they would pay changes the whole build sequence. We will shape the first release around getting one of them live.