What can a non-technical founder actually check

You cannot read the code and you should not try. What you can check is whether done was defined before the work started, whether a demo runs on real data, whether changes are getting cheaper or dearer, and whether you could hand the whole thing to someone else tomorrow.

You are in a meeting and someone is explaining why the thing is late. There are words in it you half know. Refactor. Technical debt. The API changed. It all sounds plausible and might be completely true, and you have no way to tell, and everyone in the room knows you have no way to tell.

So a quiet story starts running. That maybe you are not technical enough. That you should have learned to code. That people like you, who know an industry but not software, are not meant to build things.

I want to take that off the table. It is wrong, it is expensive, and it is the reason good ideas die in folders.

You are not stuck because you are not capable. You cannot read the code, which is fine, because reading the code was never the control. Four other things are.

One. Was done defined before anyone built

This is the whole game and almost nobody does it.

Before a line is written, there should be a definition of done that you can check. Not a feature list. Not a specification full of nouns you would have to look up. A short document that says what the system will do, in terms of things a person does, that you could sit down and verify by looking.

The test for whether it is a real definition: could you hand it to a completely different team and get roughly the same product back? If yes, it is a definition. If no, it is a statement of intent, and statements of intent are where scope grows quietly.

If you take one thing from this page, take this one. The stall at eighty percent is almost always this failure, showing up four months late.

Two. Weekly demo, real data, you driving

Not a screen recording. Not a slide with screenshots. A working thing, on real data, and you have the mouse.

Real data matters more than it sounds. Demo data is chosen to work. Your data has the client whose name has an apostrophe in it, the record from 2019 with a missing field, the invoice that was refunded twice. That is where the eighty percent stops being eighty percent.

You driving matters for a different reason. When someone else demos, they take the path they know works. You will take a path nobody thought about, which is the same thing your customers will do.

Weekly, not monthly. A month is long enough to hide a slip and short enough that nobody feels they can raise it yet.

Three. Are changes getting cheaper or dearer

This is the best signal in the whole build and you can read it without any technical knowledge at all.

Keep a rough note of what you ask for and how long it takes. Not to police anyone. To watch the direction.

In a healthy build, changes get cheaper over time. The structure is settling, the pieces are where they should be, and by week five a thing that would have taken two days takes an hour. In an unhealthy build, changes get dearer. Everything touches everything, and a small request comes back with a long explanation of why it is not small.

We rebuilt a product that had been running two years and was landing about one change a month. After the rebuild we shipped twenty seven changes overnight. That is not a story about typing speed. It is the only number that ever mattered in that project, and it is the number you can watch from where you sit.

If the trend is going the wrong way in week three, say so in week three.

Four. Could you leave tomorrow

Ask it plainly, early, and not as a threat. If we stopped today, what do I have.

The answer you want is that the repository, the infrastructure and every account are in your name already, there is written documentation, and someone else could pick it up. Not eventually. Now.

Check this yourself rather than taking the answer. Log in to the hosting account. Log in to the code repository. If you cannot, that is not a paperwork issue to sort out at handover. That is the actual risk, live, today.

I have never seen a good builder object to this. It costs them nothing and it is the clearest signal they can give you. The ones who get awkward about it are telling you something.

What you should not try to do

Do not learn to code to check the work. It takes years to get good enough to judge quality, and you would still be slower than defining done properly, which takes an afternoon.

Do not ask for line by line explanations. You will get them, they will be accurate, and you will be no better informed. The detail is not where the answer is.

And do not use how confident someone sounds as a proxy. Confidence is not correlated with being right and in technical work it is sometimes inversely correlated. The best builders I know hedge more, not less, because they have been wrong enough times to know the shape of it.

The failure mode nobody warns you about

The thing that gets people is not the obvious failure. It is the quiet one.

I run automated systems for my own business. One of them graded advertising performance and decided which ads to keep. It ran for weeks on the wrong revenue basis. Two hundred and eighty three tests passing, every check green, no error anywhere, and it was quietly killing the ads that made money.

Another one, a recurring client report, sent nothing at all for months. Nothing errored. The job ran, the log said fine, and no file went out the door. Nobody noticed because there was no alarm for a thing that did not happen.

Both of those are mine. Both were found by a person looking at an outcome and saying that does not look right, not by any technical check.

That is your job on a build, and it is a job you are already qualified for. You know your industry. When the output looks wrong, it probably is, and you are the only one in the room who can tell.

Common questions

Should I learn to code so I can check the work

No. It takes years to get good enough to judge quality and you would still be slower than just defining done properly. The leverage is in the definition and the handover test, neither of which needs code.

What should I get at handover

The repository and every account in your name, written documentation, and a recorded walkthrough. If any credential sits with the builder rather than you, that is the thing to fix first, today, whatever else is happening.

How often should I see a working demo

Weekly, on real data, driven by you rather than watched. A monthly demo is a status report with a screen attached, and by the time it slips you have lost a month.