Here is the uncomfortable truth: a status update is written by the person being judged. Even an honest developer reports what they believe, and what they believe is usually optimistic. Developers aren’t liars. Software just hides its own progress. A screen that looks finished can be a painted wall with nothing behind it.

You don’t need to read code to get around this. You need five checks that produce evidence instead of reassurance.

Check 1: Can you use it yourself, today?

What to look at: a link you can open on your phone, running the latest work. Not a screen share. Not a video. A live link where you click the buttons.

Bad answer: “It’s not deployed yet, but I can show you on my machine.” That means the work only exists on one laptop, and nobody knows what happens when it meets the real world.

What to do: ask for a private test link updated at least weekly. Click through it like a customer would. Try to break it: wrong password, empty fields, the back button. Ten minutes of this tells you more than an hour of updates.

Check 2: Is the list of finished things getting longer?

What to look at: the list of tasks, however your developer keeps it. Count what moved to “done” this week.

Bad answer: The same items are “in progress” for the third week running. Work that sits in progress for more than a few days is almost always stuck, or bigger than anyone admitted.

What to do: ask which task has been open longest and why. A good developer answers instantly and specifically (“waiting on the payment provider’s approval”). A vague answer means they haven’t looked either.

Check 3: When something broke, what changed afterwards?

What to look at: the last time something went wrong.

Bad answer: “We fixed it” with no explanation of why it happened. If nobody knows the cause, it will happen again, usually at 2am, usually in front of a paying customer.

What to do: ask for two lines: what broke, and what now stops it from breaking that way again. If the second line is “nothing,” that’s your answer.

Check 4: Can they be away for a week?

What to look at: whether anyone but your developer could get into the product, find the code, and restart things.

Bad answer: passwords in their head, accounts under their personal email, no written notes on how anything is set up. This isn’t about trust. It’s about what happens if they get ill, quit, or you part ways badly. Your product shouldn’t be a hostage.

What to do: confirm that you, personally, own the accounts: the code storage, the hosting, the domain, the payment provider. The developer is a guest in them.

Check 5: Does the news ever include a “no”?

What to look at: the last month of updates. Count the bad news.

Bad answer: zero. Every real project has surprises, such as a service that behaves differently than its documentation says, or a feature that turns out to be three times bigger. Developers who never report any are either not looking or not telling.

What to do: reward the first bad news loudly. If the first thing you do with “this will take longer” is get angry, you’ve trained them to stop telling you.

The one artifact: the sentence to say

Use this in your next meeting, word for word:

“Can you send me a link to the current version, and tell me the one thing most likely to slip?”

Then read the answer like this:

Notice what this does. It doesn’t accuse anyone. It just asks for evidence and a risk, and both are things a competent developer already has to hand.

What we’d tell you over coffee

Most founders wait for a bad surprise before they ask these questions. By then you’ve lost weeks, and the awkward conversation is also an expensive one. Asking early feels like distrust. It isn’t. It’s how a good developer expects to be managed.

If you ask for a live link and a named risk every week, you will know within a month whether you’re on track. You won’t need to read a line of code.

And if you can’t tell, because you don’t have anyone who can interpret the answers, that is a real gap. It’s the reason our work is fixed scope and fixed price with one senior engineer: there’s a working version to open and a date to hold us to, so you never have to take our word for it.

Sources

None. This post is written from experience delivering and reviewing product work, not from external sources.

Fractional CTO — from €4,000 / month, 4–6 days a month, 30 days notice. hands-on engineering and architecture every month: the technical co-founder you have not hired yet.

It starts with a free product teardown: two hours on what you are building, what already exists, and what is actually blocking launch. You leave with a written plan and a realistic number, whether or not you work with us. Book a teardown · What it costs