Get a credible, working product in front of customers — fast.
A clickable prototype in about a month, a beta you can sell in three to four. Built by two senior people who decide what is worth building before writing it — and build it so the demo can become the product.
The idea is clear. What nobody has is proof.
We need something real in front of customers before the next board meeting.
We have a deck and a demo video. Neither one proves the product works.
Every quote comes back as twelve months and a number nobody will sign.
The last prototype we shipped became the product — and it can't take real load.
Build the smallest thing that settles the argument.
A new product is a series of bets, and the only cheap way to lose one is early. So every milestone is chosen for what it would prove — to a customer, a board, or to us — rather than for how much of the roadmap it covers.
Decide what to build before building it
A week mapping the people who will use this, the workflows worth having, and what to cut — validated with real customers, not assumed in a room. Everything after that week is cheaper because of it.
A prototype convinces people; a deck does not
You have to be convinced when you see it. So the first thing we make real is the highest-value, highest-pain workflow — the moment a decision-maker uses it, the question changes from whether to when.
Specifications first, code second
With AI the code is the cheap part; deciding what to build is not. A product with written, reviewed specifications can be regenerated on a different stack next year — one that exists only as code cannot.
Built for the second customer from day one
Tenant isolation, identity and the deployment model — SaaS, on-premise, or a customer-specific install — get decided while it is cheap. Retrofitting multi-tenancy into a POC that sold is a rewrite wearing a feature ticket.
A POC shaped like production, not a throwaway
Pipelines, quality and security gates, and load testing go in while the thing is still small, because the prototype that convinces people is the one they then expect to ship. The demo becomes the product instead of being thrown away.
Staffed for decisions, not headcount
A small senior team — a developer, an analyst, and someone who genuinely knows the users — deciding requirements, feasibility and sellability together. New products die of slow decisions far more often than of slow typing.
Something to show at the end of every month.
- Week 1
Design sprint
Personas, candidate features, ruthless prioritisation, and a validation pass with real customers — so the build starts from a decision instead of a wish list.
- ~1 month
Clickable prototype
One workflow, real enough to put in front of a customer or a board. This is the milestone that tells you whether to fund the rest, and it arrives before the budget is committed.
- 3–4 months
A beta you can sell
A minimum marketable product: multi-tenant, deployable, demonstrable — and billable. Early customers get something they can use rather than a waiting list.
- 9 months max
In production
Every build is time-boxed. A product that disappears into development for two years arrives in a market that moved, which is why we do not take that shape of work on.
We have built a new product where the bar was bank-grade.
A new banking product, proven end to end before it was sold
And where the job was to find out fast, not to deliver:
- A greenfield healthcare platform architected standards-first on cloud services, with AI tooling built into the development process rather than bolted on later.
- A two-week feasibility spike for a public-safety software vendor: a validated recommendation on whether a hard technical approach was possible at all, before anyone funded a product around it.
- Design Sprint scoping introduced for new AI products — a repeatable way for a mixed team to agree what an application should actually do.
A spike that ends in “this cannot be done the way you hoped” is a good outcome two weeks in and an expensive one a year in. Part of building new products is being willing to deliver that answer.
Client work is confidential; described here in general terms. See all three engagements — or the two people who would do the work.
Tell us what the product has to prove, and to whom.
Start with a low-commitment product scoping session: what you are trying to prove, who has to be convinced, and a straight answer about what the first month can realistically put in front of them — a prototype, a feasibility spike, or a design sprint first.