SaaS development, built to be sold, not just shipped.
A product that signs up customers, bills them, and keeps them apart.
A SaaS product is a web application plus everything that makes it sellable: more than one customer in the same system without them ever meeting, a way to sign up and pay without talking to you, and the roles and controls a buyer's IT team will ask about before they sign. Those parts are decided at the architecture stage, because retrofitting them is the expensive version.
The SaaS products we build
The pattern varies with who buys it and how they pay. These are the shapes we build most often.
B2B SaaS for a defined industry
Software for one trade that generic tools serve badly, where the value is knowing the workflow rather than out-featuring a horizontal competitor. Usually sold per seat, with the buyer and the user being different people.
- The workflow of one industry, properly
- Per-seat plans and org accounts
- Onboarding and data import
- Reporting the buyer signs off on
An internal tool turned into a product
Something you built for yourselves that customers keep asking to buy. The work is separating your own assumptions from the product: making the hardcoded parts configurable and the shared parts isolated.
- Single-tenant to multi-tenant migration
- Your assumptions turned into configuration
- Your own data separated cleanly
- First external customers onboarded
Self-serve products with a free tier
Where the buying happens without a conversation. Everything hinges on the first session, so signup, the first useful moment, and the upgrade path are treated as product surface rather than plumbing.
- Signup with no sales contact
- Free tier with real limits enforced
- In-product upgrade at the limit
- Activation measured, not assumed
Enterprise SaaS with SSO and per-tenant controls
Products sold to organisations whose security review is part of the sale. Single sign-on, audit logging, and per-tenant configuration exist because the deal needs them, not because the feature list looked thin.
- SAML and OIDC single sign-on
- Directory sync and provisioning
- Per-tenant policy and audit logs
- Data residency where required
Usage-based and metered products
Where the invoice depends on what happened. The meter has to be accurate, visible to the customer in real time, and reconcilable, because a billing dispute you cannot answer with data costs more than the invoice.
- Event metering at the source
- Live usage visible to the customer
- Credits, overage, and hard limits
- Invoices reconcilable to the events
Taking an existing product multi-tenant
A working product deployed once per customer, where every new customer is now a deployment and every fix is applied several times. The move to one shared system is a data and isolation problem before it is a feature problem.
- Isolation model chosen and proven
- Existing customers migrated in stages
- One deployment, one release path
- Per-tenant configuration preserved
How the work runs
Tell us what you need
A short written brief is enough to start: what you are building, the stack it has to live in, and the problem behind it. Someone technical reads it, not a sales rep.
passed when we reply with questions and a proposed shape
Scope and quote
We agree what the first release contains and what it costs before anything is built. Anything we cannot estimate honestly gets scoped on its own rather than padded into the total.
passed when the scope and the quote are agreed
Build in the open
Working software arrives in increments, in your repository, with our commits visible from the first week. Progress is something you can open and run, not a status report.
passed when a real user is doing a real job in it
Iterate, then hand over
What the first release teaches sets the priority for the next one. When you want it in house, documentation and a handover period are part of the engagement rather than an extra.
passed when your team can run it without us
How pricing works
Fixed price per milestone
You approve each milestone and its price before it starts, so the cost is known before the work is rather than after. Milestones are sized to be worth reviewing on their own.
Monthly rate for a dedicated team
A set team at a set monthly cost, with notice rather than a minimum term. Priorities move between sprints without renegotiating anything.
Scoping first, quote after
We work out what it should be with you before quoting it. There is no charge for that conversation and no obligation to go ahead.
Frequently asked questions
What a sellable product needs underneath
Every build ships end to end, from first scope to live deployment and ongoing support.
