Hire late, build first
Why early-stage founders should ship before they staff.
The most expensive thing an early-stage founder can do is hire engineers before knowing what the product is.
A wrong engineering hire (wrong fit, wrong stack, wrong seniority) burns six months and £80,000 minimum. Two wrong hires can sink a seed-stage company. And early product is the time when wrong hires are most likely, because the product is most ambiguous. You're hiring against a spec that's going to change three times in the first quarter.
The case for building before hiring isn't about saving money. It's about not committing to an architecture or a team shape before you know what you're building. By the time you've shipped a v1 with real users on it, you know which technical decisions were load-bearing and which were arbitrary. You know what kind of engineer fits the codebase you've already started. You know whether you need a generalist or a specialist next. None of that is knowable from inside a planning doc.
We exist for that window: when the founder needs the product built but isn't ready to hire the team. We design the codebase so the people you hire afterwards can pick it up. A modern stack (Next.js, Supabase, the boring TypeScript stuff that scales without surprise), commented where comments earn their place, a README that doesn't lie, decisions documented in a docs/ folder. The handoff is a deliverable.
The founders we work with often hire their first engineer three to six months after we hand off. By that point they know who they need, and the codebase becomes a recruiting asset: strong engineers can read it before they accept the offer, and they tend to accept faster when they like what they see.
This is the studio's bias. We don't build to make ourselves indispensable. We build so the next team can take over without us.
A related point worth making: "hire late" is not "don't hire." It's "hire when you know what you're hiring for." That moment usually arrives sometime after the seed round, when the product has shape and traction and you can write a job description that won't be obsolete in a quarter. Until then, a small embedded team that ships is cheaper, faster, and lower-risk than a permanent team being onboarded into ambiguity.