SaaS product development
Building a SaaS product is a different job from building a system for one company. It has to serve customers who will never meet you, bill them automatically, survive a support queue, and stay cheap enough to run at a hundred customers as well as ten. We run five SaaS products of our own, which is how we know what year two looks like.
Is this you?
- You have a product idea and a market, but no technical team.
- Your MVP was built cheaply and now cannot take another customer.
- Every new customer needs a developer to set them up.
- You have no idea what it costs you to serve one customer per month.
- Your billing is a spreadsheet and a set of reminders.
What we build
- Multi-tenant architecture that does not need a developer per customer
- Subscription billing, plans, trials, upgrades and invoicing
- Self-serve onboarding, so a customer can start without you
- Admin and support tooling — the part founders always forget
- Usage metering, so you know your cost to serve
- Roles, teams and permissions within a customer account
- API and webhooks, because integrations become the ask by year two
- Deployment, monitoring, backups and the boring parts that keep it alive
Founders and businesses turning a proven internal system into a product, or launching a new one into a market they already understand.
- A written scope you approve before any code is written
- A price agreed against that scope, not discovered later
- Source code, database, documentation and IP yours on final payment
- Training for your team, and close support through the first month
Questions people ask about this
How do you price a project?
Against a written scope, agreed before any code is written. We do not publish indicative figures, because the same-sounding requirement can differ several times over in cost depending on the specifics.
What drives the number: how many distinct user roles there are, how many screens and reports, how much data has to be migrated from existing systems, how many other systems it must talk to, and whether your process is already documented or has to be worked out first. A first conversation is usually enough for us to tell you the rough order of magnitude.
How long does a project take?
It depends on how much of the system you want live at once, which is why we usually suggest starting with one module rather than everything.
What holds true regardless is the shape of it: you see something working every two weeks from the start of the build. You are never waiting three months to find out the project went wrong in week two.
Who owns the source code?
You do, on final payment. Source code, database, documentation and intellectual property in the work are assigned to you in the contract. There is no licence that expires and no situation in year three where you discover the software is not yours.
We also hand over in a usable state: documented, commented, and written so another developer can pick it up.
Can we start with one module and expand later?
Yes, and for most businesses it is the better way in. A first module that is live and working tells you more about whether we are the right people than any proposal does, and it limits what you risk finding out.
The one condition is that the whole system is designed at the start even if it is built in stages, so the second module does not require the first to be rebuilt.
Tell us what isn’t working
A first conversation costs nothing and commits you to nothing. Bring the problem — the mess of spreadsheets, the report nobody can produce, the process that breaks every month-end. We will tell you honestly whether custom software is the answer, and roughly what it would take. Sometimes the answer is that you do not need us. We will say so.