Building in Public #5: The need for speed

New obsession: build speed. An online app build was taking around twenty minutes end to end. Twenty minutes! People will wait that long once, out of curiosity. They will not wait it twice. So this week I declared war, with a written plan: get it to five.

The rule I set myself: no optimising by vibes. Profile first, fix the biggest number, measure again. I've been burned before: remember the parallel-lanes experiment that cost triple for zero speedup.

The first big win

The first real find was a beauty. Our verifier runs the app through a full production build to catch errors, which is correct and important. But it was doing that build every fix round, and each one cost about 137 seconds. Build once, verify the fixes against a live dev server, done: minutes off the tail of every build that needs repairs. The best optimisations feel embarrassing in hindsight; this one filed the paperwork and moved in.

Multi-tenant by default

Alongside the speed war, a foundational ship: generated apps are now multi-tenant by default. Organisations, roles, admin user management, baked in from the first build. If Vorx apps are going to be real business apps, 'add your team' can't be an afterthought bolted on later; it has to be load-bearing from day one.

Also landed: a full forms pipeline for generated sites (submissions stored, triaged, emailed, exportable), SEO finalization at publish time (proper canonical tags, sitemaps, social cards), and a fix for a genuinely nasty distributed-systems bug in the sync service, the kind where the leader election deadlocks and everything looks fine except nothing moves. Those bugs age you.

The build isn't at five minutes yet. But it's a lot closer than twenty, I know exactly where the remaining time lives, and the list of levers is written down and ranked.

That's not a dream, that's a queue.