Six weeks to a launch: the platform that makes failing affordable
Written by Codeway
Listen to this article
4:10
Introduction
Our rule is that a new app ships within six weeks of spotting the gap. That is a statement about infrastructure before it is one about ambition.
Codeway runs on a simple rule: when we find a gap in the market, an app ships within six weeks. It sounds like a statement about appetite. It is mostly a statement about infrastructure, because a six-week deadline is only meaningful if none of those weeks are spent waiting for capacity.
Most of what people call moving fast is actually the absence of friction that other companies consider normal — provisioning that takes a quarter, a data request that takes a fortnight, a GPU budget that has to be defended before an idea can be tested. Removing that is unglamorous work, and it is the work.
Deciding with data, at six terabytes a day
Every product emits events through our own SDK. Those events run through Dataflow into BigQuery, and out again into Looker dashboards the product teams read directly. The volume is roughly six terabytes a day of user behaviour.
The reason that matters is not the size of the number. It is that a product manager testing whether a feature earned its place can answer the question the same afternoon, without filing a ticket. A warehouse that is a managed service rather than a system we operate is what keeps that true — the time we would otherwise spend running it goes into the features it measures.
“Technology advances constantly, and there’s new research coming out all the time. But transforming research into actual products requires a lot of creativity and engineering work. It also requires the right technology, and for us that’s Google Cloud.”
Making GPUs cheap enough to experiment with
AI features are expensive in a specific way: the cost arrives before you know whether the feature works. That asymmetry quietly kills experiments, because a test that might cost six figures to run gets escalated instead of tried.
Two things brought that down. Fault-tolerant workloads moved onto Spot instances, and inference was placed deliberately rather than conveniently — specific GPU types in specific regions, chosen for price and availability rather than defaults. Together they cut GPU costs across our AI applications by around seventy percent.
- of event data analysed per day
- 6TB
- lower GPU cost for AI workloads
- ~70%
- from launch to one million users
- 6 days
The six-day figure is the one that tests the architecture. An avatar app we launched found its audience immediately and reached a million users inside a week — the kind of curve that, on infrastructure you have to re-architect under load, becomes an outage story instead of a growth story. APIs and models sit on Kubernetes with Pub/Sub between services precisely so that the answer to sudden success is more capacity rather than a rewrite.
Fail fast, but mean it
Failing fast is repeated so often that it has stopped meaning anything. In practice it requires two uncomfortable things. The cost of an attempt has to be genuinely low, or nobody will make enough attempts to learn anything. And the measurement has to be good enough that you can tell a bad idea from a bad launch — otherwise you kill the wrong ones.
The six-week rule holds because the platform underneath it makes both true at once. That is also why it has kept holding as the portfolio grew from a handful of apps to products serving more than six hundred million people: the constraint we designed for was the speed of a single experiment, and it happened to be the thing that scales.



