The half-hour rule

The marketing copy says "about half an hour from a paragraph to a working website." That number isn't a marketing rounding. It comes straight off the build records: the last seventeen builds ran between thirty and forty minutes, with a median of thirty-eight. 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 half an hour 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:

That default isn't wrong, but it isn't always right. For some kinds of work, the time the work takes is 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 (half an hour, twelve minutes, two minutes), there's a cultural lag. Customers don't yet trust that something built in half an hour 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 half an hour is doing

The half hour is doing several jobs.

It's a coffee break. A working half hour 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 half an hour 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 does pass through several distinct stages: architecture, brief, design language, layout, copy, photography, quality gate, post-processing. 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. Half an hour 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 half an hour 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 "about half an hour" is, in their case, a strange thing to optimise for. They wanted ten minutes. They got thirty-eight. They're a tiny bit disappointed even though thirty-eight is fine.

That disappointment is real and worth naming. We've decided to wear it, because the alternative is racing to the bottom on speed, telling customers we'll build in two minutes. That 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 half an hour 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 half-hour 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 half an hour. 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 it.

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 half-hour one, and anyone telling you otherwise is selling something. We're sticking with the half hour for the foreseeable.

What we'd ask the customer

If you've just submitted a brief and you're sitting with a coffee waiting half an hour 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.

Updated August 2026. This piece originally said twenty-five minutes. The build records have since settled around half an hour, so the figures here are the real ones. The argument did not change; only the clock did.