The product itself, built to outlive the launch
A working application with the architecture, infrastructure and tests behind it — designed so the decisions you can't undo are the ones you'd make again at ten times the traffic.
What you actually get
A product your customers can use and you can bill for. Not a prototype that demos well and falls over at fifty concurrent users, and not a design file with a note saying engineering is next.
The work covers the interface people touch, the services behind it, the database schema that decides what questions you'll be able to answer in a year, and the infrastructure it all runs on. One team holds all four, because the seams between them are where projects usually break.
The decisions that matter are early and quiet
Most of what determines whether a platform survives its second year gets decided in the first fortnight, before anything is visible. How you model a customer. Whether billing is a column or a service. What happens when a payment half-succeeds.
These are cheap to get right at the start and expensive to change once real data is in production. We spend the design phase on them deliberately, and we write down why each call was made — so when someone asks in eighteen months, the answer isn't a shrug.
Built to be handed over
You get the repository from day one, with commit access and CI visibility. Everything is documented, tested and deployable by someone who wasn't in the room.
If you hire an in-house team next year, they inherit something they can read. That's a design constraint we work under, not a favour at the end.
What's included
- Web application
- The product, built as a real application rather than a prototype.
- Mobile-first interface
- Designed for the screen most of your users will actually hold.
- Cloud infrastructure
- Provisioned as code, so environments are reproducible.
- Public API
- So integrations and a future mobile app aren't a rewrite.
- Test suite
- Enough coverage that someone else can change the code safely.
- Documentation
- Architecture decisions and runbooks, written as we go.
Where we've done this
- Healthcare
A licensed-clinician marketplace that existed as a spreadsheet and a waiting list.
Read the build - Fintech
A payments product that needed to clear compliance before it could clear a transaction.
Read the build - Aviation
A marketplace for aircraft parts, replacing the WhatsApp groups and spreadsheets MRO buyers were sourcing from.
Read the build
Questions we get asked
Our builds have run between six and fourteen months from first call to handover, with the median around nine. The variance is mostly compliance and integrations: a product that has to clear a regulator takes longer than one that doesn't. We give you a phased timeline after discovery, not before.
Yes, entirely, and from the first commit rather than on final payment. IP assignment is in the contract and you have repository access throughout. There is no scenario where finishing the relationship means losing the product.
Usually React and TypeScript on the front end, Node or Python behind it, and Postgres unless there's a reason not to. We pick boring, well-documented tools on purpose — the goal is that your next hire already knows the stack, not that we got to try something new.
Often, yes. We start with a paid audit rather than a promise: a week reading the code and the infrastructure, ending in an honest assessment of what's salvageable. Sometimes the answer is that a rebuild is cheaper, and we'd rather tell you that up front than discover it in month three.
Then we work alongside them rather than around them. That usually means we take the parts your team hasn't done before — infrastructure, model integration, the payments path — while they keep shipping product. Same repository, same standards.