Non-Technical Founder? How to Tell If Your Dev Agency Is Telling You the Truth

You hired an agency because you cannot build the product yourself. That same fact means you cannot check their work. Every deadline, every estimate, and every explanation for a delay comes from the people who benefit when you accept it.

Most agencies are decent. They want the project to succeed, they want the reference, and they want you to come back with phase two. But some are stretched across too many clients, some put their juniors on your account, and a few are simply coasting. From where you sit, all four look identical: same confident updates, same plausible reasons things slipped.

This article gives you ways to tell the difference without learning to code. None of them require technical knowledge. All of them require you to ask for evidence instead of reassurance.

Why you cannot tell on your own

When you buy a house, you do not take the seller's word for the condition of the roof. You pay a surveyor a few hundred pounds to check, because the seller knows things you cannot see and has reasons not to volunteer them.

Software has the same structure, with one difference: the survey never happens. The agency writes code you cannot read, deploys it to accounts you may not control, and reports progress in a vocabulary it also controls. When a sprint slips, the explanation arrives in that vocabulary. You can accept it or you can argue, but you cannot verify it.

This is not an accusation. It is just the shape of the relationship. An honest agency sits inside the same information asymmetry as a dishonest one. The question is not whether your agency is lying. The question is whether you have any way of knowing.

Warning signs worth taking seriously

Any one of these on its own can be innocent. A pattern of three or four is not.

• **Every delay has a fresh technical explanation.** Last month it was a library upgrade, this month it is a database migration, next month it is refactoring. Each reason is plausible. The pattern of a new reason every time is the tell.
• **Demos only run on their machines.** You watch the product over screen share, or through a link that works during the call and nowhere else. Months in, there is still no environment you can open from your own laptop on a Tuesday night.
• **You do not have admin access to your own assets.** The code repository, the cloud account, the domain, the app store listing. If any of these live solely in the agency’s accounts, you do not own your product. You rent it.
• **Estimates only ever grow.** Scope changes cut both ways. If ten change requests all added time and none ever removed any, someone is padding.
• **Resistance to outside review.** "It would slow us down." "The codebase is complex, an outsider will not follow it." A competent team is mildly annoyed by a code review. Only a worried one fights it.
• **Invoices describe activity, not outcomes.** "40 hours: backend development" tells you nothing. You are paying for effort you cannot see instead of results you can.

Six questions that need no technical knowledge

You do not need to understand the answers technically. You need to watch how easily they arrive. Honest answers to these questions are quick and boring. Evasive ones come with hesitation, jargon, or a promise to get back to you.

1. **Who owns the code repository, the cloud account, and the domain?** The right answer is you, with the agency added as a collaborator. If the answer is "we manage all that for you", ask for ownership to be transferred this month and watch the reaction.
2. **Can I open the staging environment right now, from my laptop?** Not a demo, not a video. A URL and a login that work whenever you feel like checking. If this does not exist after the first few weeks of a build, ask why.
3. **If we stopped working together tomorrow, what would handover involve?** A good agency can answer in two minutes: here is your repo, here are your accounts, here is a README, budget a week of calls. A bad one describes a long, expensive, vaguely defined process. The length of that answer is the size of your lock-in.
4. **Can you walk me through what was committed this week?** You are not reading the code. You are looking at the rhythm: steady commits from named people, or a suspicious flurry the day before your call.
5. **Which parts are behind, and why, in one sentence each?** Every real project has something behind schedule. An agency that reports all green either is not tracking honestly or thinks you cannot handle bad news. Neither is safe.
6. **Would you be comfortable with an independent engineer reviewing the codebase next month?** You are not even committing to the review. You are pricing their confidence. "Sure, whenever" is what competence sounds like.

What honest agencies do differently

It is worth knowing what good looks like, partly so you can recognise it and partly so you do not punish an agency that is actually doing well.

Good agencies put everything in your accounts by default, without being asked. They keep a staging environment you can open at any hour. They report in outcomes: what a user can do this week that they could not do last week. They flag their own slippage before you notice it, and their estimates come as ranges with the assumptions written down.

Above all, they welcome scrutiny. An agency proud of its work treats an outside reviewer as a chance to show off. We have been on both sides of this: agencies whose code we reviewed and found solid, and founders we had to tell that two years of invoices had bought them one year of software.

Getting an independent read

If the questions above leave you uneasy, you have two options, and they are not exclusive.

A one-off technical review. An independent senior engineer spends a day or a few days in the codebase, the infrastructure, and the delivery history, then gives you a written picture: what state the product is in, whether the pace matches the spend, and what to fix first. This is the surveyor model. It costs a fixed fee and removes the guesswork in one pass.

Ongoing oversight. A fractional CTO joins your side of the table for a few days a month: attending sprint reviews, reading pull requests, checking estimates against the codebase. Prodevel does this for founders regularly, acting as one technical voice across agencies, freelancers, and internal developers. The interesting part is what happens on day one. When an agency learns that someone technical now reads their pull requests, delivery behaviour tends to improve before anyone writes a single finding.

Which one you need depends on what the review turns up. Plenty of founders get a one-off review, hear that things are broadly fine, and sleep better for six months. Others discover the gap between the invoices and the codebase and want a permanent set of eyes. Either way, the money is small next to what you are paying the agency, and next to what six more months of not knowing would cost.