You are getting three quotes. They all demo well. Two of them are within a few thousand of each other and the third is half the price.
You cannot judge the code and nobody expects you to. But you can judge the answers.
Here is the thing a demo can never show you. A demo shows the part that works — the happy path, the screen where everything goes right. The money dies in the other twenty percent: what happens when two people click at once, when a payment provider is down, when someone types something ridiculous, when it is three in the morning and nobody is watching.
These eight questions go straight there. Ask them in the room. You are not marking the answer. You are watching the shape of it.
The eight
- 1. What happens if this runs twice? Systems retry. Networks hiccup. If the answer involves a shrug, ask what happens if a customer is charged twice, or an order ships twice.
- 2. Show me where it breaks. What is the worst thing someone could type in? Every real builder has a list. It is usually funny and very specific.
- 3. Who can log in and see everything? Show me that screen. Not a description of permissions. The screen.
- 4. What happens when the payment provider or the email service is down? Not if. They all go down. The question is whether your work is lost or held.
- 5. If I fire you tomorrow, what does the next person need? Show me it exists. Existing, today, not promised at handover.
- 6. How will I know it’s working at 3am when nobody’s watching? Silence should not be the only signal that things are fine.
- 7. What did you decide not to build, and why?
- 8. Restore the backup. Not take one — restore one, in front of me.
How to read the answers
You do not need to evaluate the technical content. There is a pattern in the delivery that is far more reliable, and once you have seen it you cannot unsee it.
A real answer gets shorter and more specific. It names a thing. A screen, a file, a failure, a decision. It frequently includes a small admission — “that one bit is ugly”, “we handle that badly at the moment, here is the plan.”
A bluff gets longer, warmer and more confident. It reassures. It talks about experience, process and best practice. It never contains a specific failure, a specific screen, or a specific file.
Listen for length. That is genuinely most of it.
Question 7 is the one that ends it
If you only ask one, ask what they decided not to build.
Every engineer who has actually made a system work has a list of things they refused, and can say why in one sentence: it would have doubled the timeline for a feature two people would use; it would have made the data model unable to change later; the client wanted it and it would have made the thing slower for everyone.
Somebody who has never made an engineering trade-off has no list. They will say they build whatever you need. That sounds like great service and it is a red flag, because a project where nothing was ever refused is a project where nothing was ever weighed.
Question 8 is the one nobody expects
Everybody takes backups. Almost nobody has watched one come back.
A backup that has never been restored is a belief, not a safety net. The restore is where you find out that the file was empty, the process needs a password nobody has, or it takes eleven hours and the business cannot be down for eleven hours.
Asking to see a restore is not aggressive. Any team that has been through a real outage will find it a completely reasonable request, and some of them will look pleased that you asked.
Why I trust this test
I spent four years running a technical support team at Pantheon, a hosting platform for sites that could not go down, and five years before that on service desks. That is a long time hearing people explain systems under pressure, and it is where the length-of-answer pattern comes from — not from a book.
The engineers who had actually built the thing answered in fragments and specifics. The ones who had not talked in paragraphs about the general shape of things. The confident, warm, unspecific answer was the tell every single time, and it took me an embarrassing number of tickets to notice it consciously.
I have also been on the wrong side of it. I built a hosting control panel fast, with an AI agent doing the typing, and I would have answered question 6 with something vague and cheerful. Then hours went into bugs that should not have existed, and the agent kept reporting success while nothing worked. Better prompts did not fix it. Intelligence bolted onto a bad structure is not intelligence — it is faster chaos. Question 6 would have caught me.
Using these without being difficult
- Send them in advance if you want considered answers rather than a performance. The ones who prepare properly will thank you.
- Ask all eight of every quote, including the one you already like. Especially that one.
- Write down the answers, not your impression of them. Impressions are what good salespeople manage.
- Ask a follow-up on anything longer than a paragraph. “Can you give me the specific example?” Silence after that question is data.
- Do not penalise an honest gap. “We do not do that well yet, and here is what we would do instead” is a better answer than a confident yes.
Nothing here requires you to become technical. It requires you to notice what a specific answer sounds like — and you already know that, from every other trade you have ever hired.
What to do next
Take these into your next quoting conversation. Write the answers down as they are given rather than your impression afterwards, and ask a follow-up on anything that runs long.
If you want to arrive with more than questions, map where your work stops first — a quote answered against a described process beats one answered against a wish.
If you want the whole picture instead of one workflow: tell us what’s still manual. You get a map of every point where your business stops and waits for a person, what that costs you in hours, and which of those an engine would take over first. Free, yours to keep, and useful even if you never hire us — including on the days the honest answer is that you should not build anything yet.
Common questions
Won’t asking these make me look like I don’t trust them?
It has the opposite effect on the people worth hiring. A team that has cleaned up after a bad build will read these as a client who is going to be reasonable when something goes wrong. If someone is offended by being asked what happens when their email provider is down, you have learned something valuable for the price of a slightly awkward moment.
What if all three quotes answer badly?
Then you have learned something real about your shortlist and you should widen it rather than pick the least bad. It also happens that a small shop answers well on some and honestly badly on others — that combination is frequently the best available option, because the honest gap is the part they will tell you about later too.
Do these apply to no-code and off-the-shelf builds?
Most of them, with small rewording. Questions 1, 4, 5, 6 and 8 apply to anything that runs your operations regardless of how it was assembled. If the answer to 5 is that the whole thing lives inside one person’s personal account on a platform, that is exactly the situation the question exists to surface.
Is the cheapest quote always the risky one?
No, and assuming so costs people money. A low quote can mean a smaller scope honestly described, a template approach that genuinely fits, or someone who works efficiently. What matters is whether the difference is explained. Ask what the low quote leaves out and compare that answer to the other two — the gap is usually in exactly the twenty percent these questions are about.