When to build it yourself, and when to hire
There's a real version of this decision that isn't just “hire us.” No-code tools and a technical co-founder can genuinely get an early idea to a testable state, and for validating whether anyone wants the thing at all, that's often the right first move. Hiring a studio to build a polished product around an unvalidated assumption is how founders spend £40k proving nobody wanted it.
The line worth drawing is this: DIY and no-code are for learning — testing demand, getting something rough in front of users, finding out if the idea holds. A studio is for building the thing properly once you know it's worth building — when the product has to work commercially, scale without breaking, and hold up in front of paying customers, investors, or a more serious market. The mistake in both directions is using the wrong tool for the stage: over-building an unvalidated idea, or trying to scale a no-code prototype that was never meant to carry a real business.
We've lived this on our own ventures. One started deliberately DIY — a lightweight low-code setup, built to validate the idea fast rather than overbuild on day one. It worked: it shaped the concept, tested the flow, got something live. The ceiling appeared the moment the product had to behave like a real platform instead of a prototype — custom user flows, proper data structure, real search and filtering, payment logic, admin control, a front-end that could carry a premium experience. That was the point the DIY setup stopped being an advantage. The thing that let us move fast at the start became the thing limiting what the product could become. The rebuild wasn't vanity; it was forced by complexity the early system was never built to hold.
What actually separates a serious studio from a cheap one
Price is the obvious difference and the least useful one. The things that actually determine whether a build succeeds are harder to see from a proposal.
Who does the work
The single biggest tell. Many agencies sell you a senior in the pitch and hand the build to juniors once the contract's signed. The person who understood your business in the first meeting should be the person making the decisions in the build. Ask directly who writes the code and makes the product calls — and whether that changes after you sign.
Whether they've built for themselves
A studio that has only ever billed clients has never lived with the consequences of its own decisions. We build and run our own products — SoissonsBelles, sellyourboat.io, Waaza, Loopa — and that changes how we build for you, because we've felt the thing an agency never has to: a build is never finished at launch. You live with every weak assumption, every unclear flow, every slow page, every missing piece of trust — the parts that look fine in a handover and start costing you attention, conversion, and momentum in the real world. Studios that only bill clients ship and leave. We've had to stay and live with what we made.
Whether they'll tell you no
A serious partner pushes back on the spec when the spec is wrong. A client once wanted to keep adding pages and surface-level changes, because more sections felt like visible progress. We said no. More pages wouldn't fix the real problem — the structure didn't make the offer easy to understand, trust, or act on. So instead of executing the requested scope, we pushed to tighten the core journey first: what the business does, who it's for, why it's credible, what the visitor should do next. Sometimes the useful work isn't saying yes to the deliverable. It's stopping a business from spending more money building on a weak foundation. A shop that just executes whatever you asked for is optimising for an easy invoice, not a product that works.
What happens after launch
Cheap builds end at handover. The real question is what the thing looks like six months in, when it needs to evolve — and whether the studio thinks that far ahead before the invoice is paid.
The questions a smart buyer asks before signing
Each of these surfaces something a proposal is designed to hide. Ask them out loud and watch how quickly the answer comes.
- “Who specifically will be doing the work, and does that change after I sign?” — surfaces the senior-in-the-pitch, juniors-in-the-build switch.
- “Have you built and run your own products, or only client work?” — separates operators from executors.
- “What would you push back on in what I've described?” — a good partner already has an opinion; silence is a red flag.
- “What does this look like six months after launch?” — tests whether they think past handover.
- “Who owns the code and the IP when it's done?” — the answer should be you, unambiguously.
- “Show me something you built that's still running.” — live product beats a portfolio of screenshots.
- “What's not included in this price?” — surfaces the scope games early.
On ownership specifically, our own answer is the one to hold others to: once the project is complete and final invoices are paid, you get full handover of the codebase and the IP for everything built for you — no lock-ins, host it or extend it or move it wherever you like, with only the normal third-party licences (fonts, plugins, SaaS tools) carrying their own terms.
The red flags
The proposal is vague on who does the work. The price is suspiciously low — which usually means juniors, offshoring you weren't told about, or scope that balloons later. They agree with everything and challenge nothing. They can't point to a single live product they built and still run. Code ownership is fuzzy or “to be discussed.” The senior you met in the pitch goes quiet after signing. Any one of these is a conversation; several together is a decision.
The cheapest build is rarely the cheapest outcome. Cheap work creates expensive drag — and premium done once is usually cheaper than cheap done twice.