The marketing copy says "roughly twenty-five minutes from a paragraph to a working website." That number isn't a marketing rounding. It's the actual median build time, plus a few minutes of headroom for the slower briefs. It's also, deliberately, longer than the build needs to be.
We could probably get it to twelve or fifteen minutes if we wanted. The technical constraints aren't tight at the moment. We've chosen not to. This piece is about why.
What "fast" optimises for
In most software, faster is better. The build that takes twenty-five minutes can be the same as the build that takes twelve, and if it can be twelve, it should be twelve, because the customer gets their thing sooner. There's a benevolent default in the industry that runs:
Speed is a virtue. Latency is friction. Always reduce friction. 🏎️
That default isn't wrong, but it isn't always right. For some kinds of work, the time the work takesis part of what the customer is buying. They're not buying just the output; they're buying the credibility that comes from the output having taken some time to make.
A bottle of wine that ferments in twenty minutes is a different product from one that ages for two years. They might both be drinkable. They are not interchangeable.
A meal at a restaurant is the same — the food at McDonald's is engineered for speed, and there's a place for it, but you wouldn't want a Michelin-starred restaurant to deliver your tasting menu in fifteen minutes. The pace of the meal is part of the experience. Slow is part of the offer.
Websites have, until very recently, been slow by necessity. A traditional agency build took six weeks because that's how long the work took. Customers got used to that timeline. They built their expectations around it. The website was never going to be ready quickly because the work itself was slow.
When the work suddenly becomes fast — twenty-five minutes, twelve minutes, two minutes — there's a cultural lag. Customers don't yet trust that something built in twenty minutes is good.They've learnt over decades that quality takes time, and now they're being offered quality at speeds that violate that learning. Their instinct is to be suspicious.
What twenty-five minutes is doing
The twenty-five minutes is doing several jobs.
It's a coffee break.A working twenty-five minutes is roughly the time to make a coffee, sit down with it, drink it, do a bit of email, and come back. That's a comfortable interval for a customer who's just submitted a brief. They get to do something else and come back to a finished thing. They don't have to sit and watch.
It's enough time to feel like real work. A site built in two minutes feels like a magic trick. A site built in twenty-five minutes feels like considered effort. That's not a marketing illusion — it's the real time it takes to do the considered effort. We're choosing not to compress past the point where the work is genuinely happening at the pace we want it to happen at.
It's enough time for the platform to think. The actual generation pipeline — architecture, brief, design language, layout, copy, photography, quality gate, post-processing — does pass through several distinct stages, and each one wants room to make decisions properly rather than rushing. We could parallelise more aggressively and shave time off, but the trade-off is small enough quality drops in each stage that compound across the build.
It's enough time for the customer to read. When the build is happening, the customer can watch — sections appearing, copy filling in, photographs settling. The watching is part of the experience. Twenty-five minutes is roughly the right length to keep someone interested without losing them. Two minutes is too short to feel meaningful; an hour is too long to maintain attention.
It's enough time for me to drink another coffee.This isn't a joke. The build runs in the background; my role on each customer build is light-touch (I'm reviewing the gate output, not executing the build). The pace lets me give each customer's site a careful look without rushing.
The honest weakness
There's a customer for whom twenty-five minutes is too long, and we should acknowledge them. They're the customer who's submitting at 23:55 on a Friday because they need a site for their Saturday market stall. For them, faster genuinely is better.
We can serve them — the build will run overnight if they want, and the site will be live by Saturday morning. But the marketing copy that emphasises "twenty-five minutes" is, in their case, a strange thing to optimise for. They wanted ten minutes. They got twenty-five. They're a tiny bit disappointed even though twenty-five is fine.
That disappointment is real and worth naming. We've decided to wear it because the alternative — racing to the bottom on speed, telling customers we'll build in two minutes — would attract a different kind of customer altogether: the one who's optimising for "is it ready yet" over "is it good", and who'd then be unhappy about every other slow-craft trade-off we make.
The customer we want is the one who'd accept twenty-five minutes for the same reason they'd accept five days for a site rescue or three months for a custom brand identity: because slow-enough-to-do-well is a feature, not a bug.
What we could change
To be transparent: the twenty-five-minute floor is a current number, not a permanent one. Things that could reasonably move it:
- Significant platform improvements. If our underlying tooling gets meaningfully faster (which it will), we'll absorb the speedup but probably keep the user-facing number around twenty-five — the work expands to fill the time, mostly with extra quality work.
- Customer demand for faster. If a meaningful chunk of customers tell us they need under-fifteen-minute builds, we'll consider an "express" pathway. We'd charge for it differently — speed costs. Not because the compute costs more (it doesn't), but because the speed signals a different kind of customer relationship that's worth different money.
- Specific use cases. A "brief refresh" path (rebuilding a single page when a customer changes their mind, rather than the whole site) could legitimately run in five minutes. We're considering this for Issue 03 territory.
What won't move it: pressure from competitors who claim "instant" builds. That's the wrong race.A two-minute website is, today, a worse product than a twenty-five-minute one, and anyone telling you otherwise is selling something. We're sticking with twenty-five for the foreseeable.
What we'd ask the customer
If you've just submitted a brief and you're sitting with a coffee waiting twenty-five minutes for the build, treat the wait as part of the deal. The site you're getting is being made now, by something that's taking the brief seriously. The pace isn't padding. It's the work happening at the speed the work happens.
Make a second coffee, if it helps.