Free, nothing hidden
Are your developers doing a good job?
14 things you can check without reading a line of code. Each one comes with how to check it, what a yes looks like, and what to do when the answer is no.
The short answer
The short answer
You can answer this without reading code. Ask for a link that shows the newest version, and open it yourself. Check that the code and the hosting accounts are in your company name rather than the supplier’s. Ask whether anyone besides one person can deploy. Ask what happened the last time something broke, and how long it took to fix. Ask whether you get a written note of what shipped. Those five take an afternoon, need no technical knowledge, and catch most of what goes wrong. What they cannot tell you is whether the software is any good, which needs somebody technical reading it.
Nothing answered yet. Work down the list. Several of these you can check in the next ten minutes.
Can you see the work?
The cheapest fraud and the commonest honest failure look identical from outside: no visible output. This group costs nothing to check and catches both.
Can you open a link right now and use the newest version yourself?
How to check. Ask for the staging link. Open it. Use it. If it needs a screen share or a scheduled demo, the answer is no.
A yes looks like
A link you can open whenever you like, showing work that is newer than the last demo.
A no usually means
Progress is only visible when they show it to you. Every serious problem this tool can find hides behind that arrangement.
Has anything visibly changed on that link in the last week?
How to check. Look at it on a Monday. Look again on Friday. You do not need to understand the change to see that there is one.
A yes looks like
Something is different, most weeks, and they can tell you what.
A no usually means
Weeks pass with no visible change. Sometimes that is genuine backend work. Often it is not, and the way to tell is whether they can say specifically what changed and where you would see it.
Do you get a written list of what shipped, without asking?
How to check. Look in your inbox or your shared channel. Is there a note, dated, listing what went out?
A yes looks like
A short written list arrives on a rhythm. It does not need to be formal.
A no usually means
You find out what shipped by asking, or by noticing. That makes it impossible to tell later what was delivered when.
When something takes longer than estimated, do you hear about it before the deadline?
How to check. Think about the last three slipped dates. Did you learn about each one in advance, or on the day?
A yes looks like
You hear early, with a reason. Software slips; hiding the slip is the problem rather than the slip.
A no usually means
You find out on the day, or after. That pattern means the plan is not being tracked against, and the next date is not a forecast.
Do you own what you paid for?
The single most expensive thing to discover late. Founders routinely find out in month nine that the code, the accounts or the domain are not theirs.
Is the code in an account your company owns?
How to check. Log in yourself. If you cannot log in, or the account belongs to the agency or a contractor, the answer is no.
A yes looks like
Your company owns the account. Developers have access to it, which is the correct direction round.
A no usually means
The code lives with the supplier. This is the most common expensive surprise in early startups, and it is discovered at the worst possible moment, which is when you want to leave.
Are the hosting, domain and third-party accounts in your company name?
How to check. Make a list of every service the product depends on. Check who the billing email belongs to on each.
A yes looks like
Your company is the account holder and pays the bills directly.
A no usually means
Somebody else holds them, so somebody else can switch your product off, and their departure or dispute becomes your outage.
Is there a written document explaining how to run and deploy the thing?
How to check. Ask to be sent it. You will not understand all of it. You are checking that it exists and is more than a page.
A yes looks like
A document exists, and it has been updated more recently than the day it was created.
A no usually means
The knowledge is in somebody’s head. That is fine until it is not, and the price is paid entirely by you.
Is it safe to change?
A codebase nobody dares touch still works today and cannot be improved. This is what "we need to rewrite it" means eighteen months later.
Is there something automatic that checks the product still works before a change goes out?
How to check. Ask to be shown it running, on a screen share, once. You are looking for a list of green ticks, not for understanding.
A yes looks like
They can show you it running, and they can tell you roughly what it covers.
A no usually means
Checking is manual, or it is somebody clicking around. That works at this size and it is why the fourth month is slower than the first.
The last time something broke in production, how long until it worked again?
How to check. Ask. You want a number in minutes or hours, and a description of what they did.
A yes looks like
A specific answer, and it includes the ability to undo a change quickly.
A no usually means
Vagueness, or a long time, or nothing has ever broken. The last one usually means nothing has shipped.
Do you know how much of this was generated by AI, and has a person read it?
How to check. Ask directly. It is a normal question in 2026 and a good team answers it without defensiveness.
A yes looks like
A straight answer, and a description of what gets reviewed. Generated code is not a problem. Unreviewed generated code is.
A no usually means
Discomfort, or a claim that none of it is. The failure mode is a codebase that works in the demo and that nobody, including the people who shipped it, fully understands.
Is anyone accountable?
Not about trust. It is about whether one person leaving, or one week of illness, stops everything.
If your main developer disappeared tomorrow, could anybody else deploy?
How to check. Ask who else has done it, and when. You want a name and a recent date.
A yes looks like
A second name, who has actually done it, recently.
A no usually means
One person. Very common and not a scandal at this size, and it means one holiday or one argument stops your company.
Is it clear who decides what gets built next, and is that person you?
How to check. Look at the last three things that shipped. Ask yourself who chose each one.
A yes looks like
You decide, informed by them. They push back, which is what you want.
A no usually means
Things appear that you did not ask for, or your requests quietly do not arrive. Both mean the roadmap is being set by whoever is nearest the keyboard.
Do they ask you awkward questions about the details?
How to check. Think about the last feature. Did anybody come back to you about an edge case you had not considered?
A yes looks like
They ask, sometimes annoyingly. Questions before building are the cheapest thing in software.
A no usually means
Everything is always fine and nothing is ever unclear. That usually means assumptions are being made silently, and you will meet them as rework.
Have you ever had a second opinion on a quote or an estimate?
How to check. Recall whether any significant number was ever checked by somebody with no stake in it.
A yes looks like
Yes, at least once, on something significant.
A no usually means
Never. Two independent estimates on the same written scope tell you more than any amount of reassurance, and one quote is not a price, it is an opening position.
Where you stand
Not checked yet
- Can you see the work?
- Do you own what you paid for?
- Is it safe to change?
- Is anyone accountable?
What this cannot tell you
Every signal here is one a founder can check without reading code, which is what makes it usable and also what limits it. A team can pass all of this and still be building the wrong thing, or building it badly in ways only another engineer would see. This finds neglect, disorganisation and misaligned incentives. It does not assess whether the software is any good, and it is not a substitute for somebody technical reading the actual code.
If the answer is that you need somebody technical
It does not have to be a full-time CTO.
Ten to twenty hours a month covers most of what is on this list: reading the code an agency delivers, sitting in the interviews, and pricing a vendor before you sign.
Fractional CTO
A written technical assessment inside the first thirty days, then a ninety-day plan with milestones somebody outside the company could check. One month notice either way.
One limit worth stating
Everything here is checkable by somebody who cannot read code, which is what makes it usable and also what limits it. A team can clear every signal and still be building the wrong thing, or building it badly in ways only another engineer would see.
This is a smoke alarm rather than a survey. It finds neglect, disorganisation and misaligned incentives, which between them account for most of what goes wrong on an early build. It does not assess whether the software is any good, and no list of questions a non-technical founder can ask ever will.
FAQ
Questions about this check
Next step
If several answers came back no and you would rather somebody technical looked properly, that is a 30-minute call and you will get an opinion on it.