Product pod
A small cross-functional team — product, design, engineering — that owns an outcome end to end.
Net-new builds and serious modernisation.
How we work
Four phases, and the last one never ends.
The same sequence we use on our own products. It is deliberately unglamorous: agree what matters, de-risk the part that can sink it, ship in weekly slices, then keep it running.
- 011–2 weeks
Frame the problem
Before anyone opens a design file we agree on what has to move, what the current systems can and cannot do, and the number that tells us it worked.
What you get
- A written problem statement and the metric attached to it
- An audit of the systems already in place, including what is quietly broken
- Scope split into what ships first and what waits
- 022–4 weeks
Design and de-risk
Interface design and technical architecture together, plus a working prototype of whichever part we are least sure about. On integration work that is almost always the third party.
What you get
- Screens and states, including the empty and failed ones
- Data model, API contracts and the auth boundary
- A prototype against the real third-party API, not a mock
- 034–10 weeks
Build and launch
Weekly increments behind automated checks. Something is done when the whole loop closes — money, webhook, write-back, customer email — not when the happy path renders.
What you get
- Working software in staging every week
- Automated tests, CI, and monitoring wired before launch day
- Runbook covering the failure paths and who to call
- 04Ongoing
Run it
The phase most studios do not offer. We keep the pager, watch the numbers, and keep shipping — the same arrangement we have with our own products.
What you get
- Monitoring, alerting and incident response
- A prioritised backlog reviewed against real usage
- Handover to your team whenever you want it, documented
Engagement
Three ways in.
Specialist squad
Drop-in depth on one thing: a carrier or ERP integration, an AI pipeline, measurement, or edge infrastructure.
You have a team; you are missing one capability.
Operate
We run what exists — releases, monitoring, iteration, and the operational work nobody volunteers for.
Something is live and nobody owns it.
Working together
Predictable pace, no status theatre.
You should be able to tell what happened last week without asking, and never wonder whether a decision is waiting on you.
- Monday planning, Friday demo — both short, both with the client in the room
- Written async updates daily, with blockers and the decisions we need from you
- A shared channel, and a two-hour response commitment during working hours
- Everything in a repository you own from the first commit
Questions
The ones we always get.
- How quickly can we start?
- Usually one to two weeks. The framing phase is short and does not need the whole team, so it can begin while contracts are still moving.
- Do you work alongside an existing team?
- Yes, and often. We can lead a programme or take one slice of it. Our rituals bend to match yours rather than the other way round.
- What do you actually build on?
- Next.js and React Router on the web, React Native and native Swift and Kotlin on mobile, Node and Python on the server, Postgres and Prisma for data, Cloudflare Workers at the edge, Shopify for commerce, n8n for orchestration, and Claude for the agent work.
- How do you keep quality up?
- Automated tests and CI on every change, performance and accessibility checked before launch rather than after, monitoring in place on day one, and a validation gate in front of anything an AI system publishes.
- Who owns the code?
- You do, from the first commit, in your own repository and your own cloud accounts. Nothing we build depends on us staying.