Nobody Is Reviewing Your Developer

The question I get asked most often by non-technical founders is whether to hire an agency or a freelancer.

It is the wrong first question. Both work. Both fail. What separates the projects that go well from the ones that quietly consume a year is something else entirely:

Who is reviewing the work?

In most companies under 200 people, the honest answer is nobody. The founder cannot evaluate it. The operations manager cannot evaluate it. The person who can evaluate it is the same person doing it — which is not a review, it is a self-assessment.

That single gap causes more expensive failures than any choice between vendor types.

Why it stays invisible for months

Software has an unusual property compared to most things a business buys: it looks finished long before it is sound.

If a builder puts up a wall badly, you can see it. If a supplier ships poor materials, you find out on arrival. But a demo of a working screen looks identical whether the thing behind it is well built or held together with assumptions that fail the moment two customers use it at once.

So the project reports green for months. Screens appear. Meetings are positive. The problems that matter — how the data is structured, who is allowed to see what, what happens when something fails halfway through — are invisible in a demo and expensive to change later.

By the time symptoms appear, they do not arrive labelled as design problems. They arrive as "it's been slow lately," as a customer seeing something they should not have, as a report that no longer reconciles. Individually each looks like a bug. Together they are one decision made in month one.

The three decisions that are hard to reverse

Not everything needs oversight. Most of what a developer does day to day is genuinely reversible — a screen laid out badly can be laid out again next week.

Three things are not, and they are all decided early:

How your data is structured. Everything else is built on top of this. Changing it later means changing everything that touches it, which by month six is everything.

Who is allowed to see what, and where that is enforced. If access rules live in the interface rather than in the database, then the rule is "we show the right things to the right people" rather than "the wrong things cannot be retrieved." Those sound similar and are not. The second survives a mistake. The first does not.

Whether you can move. Whose accounts hold the code, the servers, the domain. This decides whether a disagreement with your vendor is an inconvenience or a hostage situation.

You do not need to understand the technical detail of any of these. You need someone independent to look at them once, early, while changing them is still cheap.

What "expensive" actually means here

I want to be careful with numbers, because the honest answer is that it varies enormously.

But the shape is consistent. A build that has to be substantially redone costs roughly what it cost the first time — plus the months in between, plus whatever the business could not do while waiting. For a company that spent a mid-five-figure sum on a custom system, the real cost of getting the foundations wrong is usually not the rebuild. It is the year.

The review that would have caught it is a fraction of a percent of that, and it happens once.

This is the part that surprises people: oversight is cheap not because it takes little effort, but because it takes little time. Looking at the three decisions above is a matter of days. Living with them is a matter of years.

If you are not going to get anyone to review it

That is a legitimate choice. Plenty of projects run without oversight and turn out fine, particularly small ones with a good contractor.

If you go that way, at least change the terms, because these cost nothing to ask for at the start and are close to impossible to obtain afterwards:

• The code repository is created in your company's account, and your vendor is added to it. Not the other way round.
• Hosting, domain, and third-party service accounts are in your company's name, on your company's card, with your email as the recovery address.
• Payments are tied to milestones you can personally verify — something you can open and use, not "backend complete."
• A working version is deployed somewhere you can see it from week two, and stays updated. Long stretches with nothing to look at are the single clearest early warning sign.

None of these require technical knowledge. They are commercial terms, and a good vendor will not object to any of them. That reaction is itself useful information.

The uncomfortable version

Most of the badly-built systems I have been asked to take over were not built by bad developers. They were built by reasonable people making reasonable decisions with nobody in the room who had seen what those decisions cost three years later.

That is not a hiring problem. It is a structural one, and it is the reason the agency-or-freelancer question matters so much less than it feels like it should.

Ask instead: who, other than the person doing the work, will look at it — and when?

If you have no answer, that is the gap worth closing first. Everything else is a preference.

Related reading: If Your Only Developer Quit Tomorrow · You Shipped an MVP With AI. Six Things Break Next.

---

If nobody is in that seat at your company, it is the role I most often end up filling - a senior reviewer on the system your business runs on, a few hours a month. Book a 30-minute call and we can see whether that is what you need.