Product engineering · SaaS
Product engineering and SaaS development
For teams building a product rather than an internal tool. The first version has to be small enough to ship and structured enough to grow, and most first versions fail one of those two tests.
The problem
The first version is usually either too small or too permanent
Cut too much and you cannot tell whether anyone wants it. Build too much and you have spent a year proving an assumption you could have tested in a week, on an architecture chosen before you knew what the product was. Both failures come from committing before anyone has used anything.
How we work on this
Prototype first, then the build you approved.
We start from the one workflow that proves the idea, put a working prototype of it in front of real users within hours, and only then decide what the first shipped version contains. The build is fixed in scope against one success measure, with the structure chosen for the extension you can already see coming, not for every extension you might imagine.
What this covers
Capabilities, and where each one stops.
-
First shippable version
The smallest version that a real user can do real work in, built so the second version is an addition rather than a rewrite.
-
Multi-tenant SaaS foundations
Accounts, roles, permissions and per-tenant data separation designed in from the start, because retrofitting them is where SaaS rebuilds come from.
-
Product analytics wiring
Instrumenting the handful of events that tell you whether the thing is being used, not a dashboard of vanity metrics.
-
Integrations your customers ask for
The two or three systems your buyers already run, built when a customer asks rather than pre-built on a guess.
-
AI features where they earn their place
Copilot, extraction or prediction inside the product, added when they change what a user can do, not to have an AI feature.
We do not take equity in place of payment, and we do not build a product for you to pitch without users. If you have not put the prototype in front of anyone, that is the next step, not the build.
How it is built
Decisions we make the same way every time.
- Web-first, and usable on a phone from day one
- One agreed success measure per build, set before work starts
- Your data exportable in open formats at any time
- Scope cut before timelines extend
- Handover written for the team who will maintain it
Where this applies
Industries we have gone deep in, and the rest of the ecosystem.
Questions
The questions people ask about this work.
Can you build an MVP in seven days?
A fixed-scope first build runs to the 7-Day Build once you have approved the prototype. Larger ideas get split so no single build runs longer, which keeps each one honest.
Will we be locked into you afterwards?
No. Your data exports in open formats at any time, exit terms are written into the agreement before work starts, and for anything beyond a pilot we will discuss source escrow.
Do you do design as well as engineering?
Yes. Interface design is part of the prototype, which is why the prototype is something you click rather than a document you read.
All questions, including the ones that might lose us the deal
Describe the product you want to build
One sentence is enough. The founder reads it and replies, usually within a business day.