You can’t tell if your developers are telling you the truth.
Neither can most founders. Twelve questions to send your dev team this week, with what a good answer sounds like and what should worry you.
- Twelve questions, grouped into visibility, ownership, resilience and continuity
- A good answer and a red flag for each, so you can judge the reply without being technical
- A scoring page that tells you whether you have gaps or a problem
Four things you are entitled to know about your own product.
Progress you cannot verify is not progress. Three questions that separate a view of the work from a summary of it.
Accounts, data and third-party services. The section founders skip, and the one that hurts when a relationship ends.
Backups, single points of failure and growth. Not whether it will break, but whether anyone has thought about it.
Most early products depend on one or two people. That is normal. Not knowing how much depends on them is not.
A date, and how long the restore took. Someone has actually tried it.
“We have backups.” A backup nobody has restored is a theory, not a safety net.
- You are paying for development you cannot personally assess
- An agency, freelancer or single developer holds the keys
- You have investors asking questions you cannot answer
- You already have a CTO you trust
- You write the code yourself
Reasonable questions
Good ones enjoy it. Every question is about the system, not the person, and most teams answer eight or nine from memory.
Yes. No call required to receive it. If you want a second opinion on the answers afterwards, that conversation is free too.
Send them over. On a 30-minute call I will tell you which gaps matter at your stage and which you can safely ignore, including if the answer is that you do not need us.
Twelve questions. One afternoon. A much clearer picture.
Free. If the answers worry you, bring them to me afterwards and we will work out which gaps actually matter.
Questions people ask about the Technical Reality Check
What is the Technical Reality Check?
A free six-page checklist of twelve questions for founders paying for software they cannot personally assess. Each question comes with what a good answer sounds like and what should worry you, and a scoring page turns your team’s replies into a picture of where you actually stand.
Who is it for?
Founders and business owners who have no CTO, usually where an agency, a freelancer or a single in-house developer holds the keys. It assumes you cannot read the code yourself. If you already have a technical leader you trust, you do not need it.
What do the twelve questions cover?
Four areas, three questions each. Visibility: whether you can see the real state of the work. Ownership: whether the accounts, data and code are yours. Resilience: what happens when something breaks. Continuity: how much of this depends on one person.
Do I need to be technical to use it?
No. The questions are in plain language and so is the guidance on each answer. What you are judging is whether a reply is specific and backed by evidence, rather than whether the engineering behind it is correct.
How long does the whole thing take?
Sending the questions takes minutes. Most teams answer eight or nine from memory and need a day or so for the rest. Reading the replies against the guidance takes an afternoon, which is where the scoring page does most of the work.
How is this different from a code audit or technical due diligence?
An audit is someone reading your codebase and reporting back, over days and for a fee. This is twelve questions you put to your own team, in an afternoon, for nothing. It is the step that tells you whether commissioning an audit is worth it.
Who wrote it?
Promise Ekoriko, founder of Prodevel and a fractional CTO based in London. The questions come from reviewing AI-generated and agency-built production codebases, and from sitting on the founder side of the same conversations.
What happens after I enter my email?
You get the checklist straight away, and a copy by email so it is there when you come back to it. If you want a second opinion on what your team sends back, there is a link to book thirty minutes.