Productising what you already do
You run a service business with a process customers value. Turning that into software is the most common and most credible route.
✦ SaaS product development
SaaS product development for B2B founders and operators
Building a product to sell is a different discipline from building software to use. Multi-tenancy, billing, onboarding and support all have to exist before your first customer does. We build first versions that can carry the hundredth customer.
✦ Who this is for
Three routes into a SaaS product
Selling your internal tool
You built something for yourself, competitors keep asking about it, and now it needs multi-tenancy, billing and someone else's data kept separate from yours.
A first product from scratch
Domain expertise, identified buyers, no software yet. The risk is building too much before anyone has paid.
✦ Foundations
What every B2B SaaS needs from day one
Retro-fitting any of these later is expensive. Building them in at the start is not.
- Multi-tenant architecture with hard data isolation between customers
- Organisations, teams and roles - B2B buyers never have just one user
- Subscription billing, plan changes, proration and failed-payment handling
- Self-serve onboarding that gets a new account to value without you on a call
- Single sign-on, because your first enterprise buyer will ask for it
- Audit logging and data export, for security questionnaires and for trust
- Usage analytics, so you can see what customers actually do rather than guess
- An admin back office for your own team to support customers without database access
✦ Scope discipline
MVP means the smallest thing someone will pay for
The most expensive mistake in SaaS is building six months of features for an imagined customer. The second most expensive is shipping something so thin that the architecture has to be thrown away at customer ten.
We aim between the two: one workflow done properly, on foundations that hold. That usually means a narrow feature set on solid multi-tenancy, billing and access control.
We will also push back on features. Every one you add before launch delays the only feedback that matters - whether anybody will pay.
✦ Path
From idea to paying customers
1
Define the wedge
One workflow, one buyer, one measurable outcome. Everything else is roadmap.
2
Build the first version
The wedge plus the foundations above, in a fixed-price release with weekly demos.
3
Launch to design partners
A handful of real customers paying real money, with feedback loops built into the product.
4
Iterate on evidence
Usage data and support conversations decide the roadmap, not the founder's favourite idea.
5
Scale the platform
Performance, reliability and enterprise requirements as the customer base and their questionnaires grow.
✦ Commercials
Equity, and why we don't take it
We build for a fee, not for a share. Equity arrangements sound aligned and usually are not: they blur who is accountable for delivery, and they make it awkward to tell a founder that a feature is a bad idea.
You own the product, the code and the upside. We are a supplier you can replace, which keeps us honest.
✦ Questions we get asked
SaaS development questions
How long until we can charge customers?
For a well-defined wedge, a first paying version is typically a matter of a few months rather than a year. The variable is scope discipline, not engineering speed.
Do you take equity instead of fees?
No. We work for a fee so accountability stays clear and you keep all the upside.
What about billing - Stripe or something else?
Stripe covers most B2B SaaS, including subscriptions, proration and invoicing. Where customers demand purchase orders and bank transfer, we build that path alongside it.
Can we take the product in-house later?
Yes, and many clients do once they hire their own engineers. The code is yours throughout, documented for handover rather than for us.
Will it handle enterprise security reviews?
The foundations are built for it: tenant isolation, SSO, audit logs, encryption and data export. Formal certification such as ISO 27001 or SOC 2 is a programme you run, and we build so it is not blocked.
Tell us what isn't working. We'll tell you what we'd build.
Thirty minutes. Bring the process, the systems it touches and the deadline. You'll leave with an approach and an honest answer on whether custom software is the right call.
No pitch deck · We map your process · You own the software