KHUFUYour V1, shipped in 7 days

Free checklist · 17-page PDF

47 questions to ask before you hire anyone to build your SaaS

The vetting checklist for founders who cannot read code — what to ask, why it matters, and the answer that should end the conversation.

  • ✓47 questions grouped into the eight areas where projects actually go wrong
  • ✓For each: why it matters, and the specific answer that is a red flag
  • ✓The five answers that should end a conversation immediately
  • ✓How to run the list in a 45-minute call without sounding like an interrogation
  • ✓The ownership clauses to check before you sign anything

Free, no account needed. A few follow-up emails about shipping V1s — reply “unsubscribe” and they stop.

Adrien De Coster

Written by Adrien De Coster, founder of Khufu — an AI-native product agency in Dubai. He writes the code on every sprint.

The hardest part of hiring someone to build software is that you cannot inspect the product until you have already paid for most of it. By the time bad work becomes visible, you have spent the budget and the calendar.

The way around that is not technical knowledge. It is asking questions whose answers are hard to fake — and knowing what a good answer sounds like before you hear one.

These are the 47 I would ask. They are uncomfortable, including for me. If a provider gets defensive at question 14 or 20, that is the checklist working — that is exactly what it costs to find out cheaply.

Who this is for

Non-technical founders about to hire an agency, a freelancer or a development team, who need to evaluate people whose work they cannot inspect.

What’s inside

  1. 01

    How to use this list

    Running 47 questions without turning a sales call into an interrogation.

  2. 02

    The five answers that should end the conversation

    The responses that are not negotiating positions — they are exits.

  3. 03

    Scope and understanding (1–6)

    Whether they understood the product, or just the feature list.

  4. 04

    Price, contract and what happens when it slips (7–13)

    Where the money actually moves when things do not go to plan.

  5. 05

    Ownership: code, infrastructure, accounts, IP (14–20)

    The section to read twice. Ownership is either concrete or it is marketing.

  6. 06

    Who actually does the work (21–25)

    The gap between who sells the project and who builds it.

  7. 07

    Technical choices and lock-in (26–31)

    Questions you can ask usefully even if you cannot evaluate the answer yourself.

  8. 08

    Process and communication (32–36)

    How you find out something is wrong — early, rather than at the end.

  9. 09

    Quality, testing and security (37–42)

    The work you are paying for that you will never see — until it fails.

  10. 10

    Launch, handover and life after (43–47)

    What happens on the day the project ends, and the month after.

Read two chapters before you download

How to use this list

Running 47 questions without turning a sales call into an interrogation.

Do not read all 47 down a call. You will sound like a procurement form and you will learn less, because the useful signal is in how someone thinks, not in whether they have a prepared answer.

Pick twelve

Choose two or three from each section that map to your actual risk. If you are non-technical, weight ownership and quality. If you have a hard deadline, weight price and process. If the provider is a team rather than a person, weight who does the work.

Ask the open ones first

Start with question 1 — "describe my product back to me in one sentence." It is the highest-signal question in the list and it takes ten seconds. Someone who repeats your feature list has not understood the product. Someone who tells you what it is for, and what they would cut, has.

Listen for the shape of the answer, not the content

  • Specifics beat reassurance. "Yes, we handle that" is not an answer; "here is how we handled it on X" is.
  • Volunteered downsides are the strongest possible signal. Anyone who tells you unprompted what could go wrong has done this before.
  • Watch for the pivot to sales. A question about ownership answered with a paragraph about their process is a no.
  • A slow, honest "I do not know, I would need to check" beats a fast confident wrong answer every time.

Get the answers in writing

For anything in the ownership and price sections, ask for the answer by email afterwards. It is a reasonable request, it takes them two minutes, and a provider who will not put an ownership answer in writing has told you what you needed to know.

The five answers that should end the conversation

The responses that are not negotiating positions — they are exits.

Most bad answers are fixable with a better contract. These five are not, and you save yourself months by walking away the moment you hear one.

  1. 1"We keep the code until final payment, then transfer it." Payment terms are fine; hostage terms are not. The repository should be in your organisation from day one, with commits landing in it as work happens. Anything else means a dispute leaves you with nothing.
  2. 2"We use our own internal framework, it makes us faster." It makes them necessary. You will not be able to hire anyone else to maintain it, and that is the point of the arrangement.
  3. 3"We can't tell you who will work on it until we start." You are buying a specific person's judgement. If they cannot name them, you are buying whoever is unallocated that month.
  4. 4"We'll figure out the exact scope as we go." Without a written scope, there is no such thing as late and no such thing as out of scope. Time-and-materials work is legitimate — but only with a technical counterpart on your side who can tell you when to stop.
  5. 5"Testing and deployment are a separate phase we can quote later." Software that is not deployed is not finished. If shipping is a separate line item, the quote you are comparing is not for a working product.

Questions

Yes — because the questions are designed so that the shape of the answer carries the signal, not its technical content. Specific beats reassuring, volunteered downsides beat confidence, and "I would need to check" beats a fast wrong answer. You are assessing how someone thinks, which you do every day in every other part of your business.

Numbers 1 (describe my product back to me), 9 (who pays for an over-run), 11 (what is not included), 20 (what stops working if I leave) and 21 (who writes the code). Those five surface most of the risk in about ten minutes.

No, and the reaction is itself data. You are about to hand someone a significant amount of money for something you cannot inspect. Any professional expects diligence; only someone with a problem finds it offensive.

Market ranges in 2026: roughly $20,000–50,000 with a senior freelancer, $60,000–250,000 with a classic agency, and $17,000 fixed for a Khufu Sprint V1 delivered in 7 days. A quote far below the range usually means no-code, offshore juniors, or a scope that will grow after signature.

Fixed price agreed before the work starts, and an over-run is the agency's cost. Adrien De Coster writes the code personally on every sprint. The repository sits on your organisation from day one with full history, and every infrastructure account is in your name. If the relationship ended tomorrow, nothing would stop working except further changes.

Get the full 17 pages

That is a genuine invitation — the list was written to be answered. Sprint V1: a SaaS or mobile app scoped, built and shipped in 7 days for a fixed $17,000, with the repository yours on day 8.

47 Questions · PDF · free · updated 2026-07-31

Free, no account needed. A few follow-up emails about shipping V1s — reply “unsubscribe” and they stop.

© 2026 Khufu FZCO · Dubai, UAE

hello@khufu.iokhufu.ioLegalPrivacy