We kept meeting companies paying two agencies to argue with each other. V12 exists to remove that seam — engineering and growth on one team, against one number.
V12 started with a pattern we kept running into from the inside: a company would hire a development shop and a marketing agency, and the two would optimise for different things. The developers shipped what the spec said. The marketers drove traffic to it. Nobody owned the gap in between, which is usually where the revenue was going.
So we built the studio around that gap. Engineers who understand unit economics. Growth practitioners who can read a pull request. One team, one roadmap, one metric agreed before kickoff — and the authority to change the plan when the data says the plan was wrong.
That structure sets a ceiling on how much work we can take, and we have chosen to keep it. A small number of engagements at a time is the only way senior people stay on the same project from diagnosis through handover.
Mission
Remove the seam between building software and growing the business that runs on it.
These are not values on a wall. Each one has turned down work or shortened a scope at some point, which is the only test that matters.
Most projects fail because they solve a real problem that wasn’t the binding one. We spend the first two weeks finding out what is actually limiting the business, and we say so plainly even when it kills the scope we were hired for.
A specification is a hypothesis. We put working software in front of real users early because that is the only reliable way to find out which parts of the plan were wrong.
We do not touch budget or performance work until the numbers are trustworthy. Optimising against bad data reliably makes things worse while looking like progress.
Documentation, tests and clean boundaries are not deliverables we add at the end. Every engagement is built so your team could own it tomorrow — including the ones where we stay for years.
We take on a small number of engagements at a time. It costs us revenue and it is the reason senior people stay on the work from kickoff to handover.
Every engagement runs through the same five phases, whether it’s a platform build or a demand programme.
Week 1–2
We audit what exists — code, funnel, data, tooling — and interview the people closest to the work. Output is a written diagnosis naming the constraint, not a list of everything that could be improved.
Week 2–3
One scope, one success metric, one sequence. We agree what we are not doing in this phase, which is usually the harder half of the conversation.
Week 3–12
Two-week increments, each ending in something demonstrable in a real environment. You see progress in the product, not in a status report.
Ongoing
Instrumented release with rollback, monitoring and alerting in place before traffic arrives. Training and documentation ship with the work, not after it.
Ongoing
A standing test queue against the current constraint, reviewed monthly. Small compounding gains beat one redesign a year.
And by implication, what we are not. We will tell you when a project needs a specialist we aren’t.
Production TypeScript, distributed systems, data pipelines and platform migrations — built by people who have operated what they shipped.
We work in your unit economics. Cost per opportunity, contribution margin and payback period, not impressions and sessions.
Governed event models, warehouse-backed reporting and honest attribution — including telling you when a number cannot be known.
Interfaces documented as systems with real states, so quality holds as the product and the team grow.
Software, web and growth programmes since 2019
From kickoff to production on build engagements
Clients continuing into a second engagement phase
Measured on mobile at launch across shipped sites
Sample figures shown for layout. Replace with verified numbers before publishing.