Skip to content
The Lean CPTO
Menu
Get the kit · US$47

Guides

Should you build your app or sell it first? Take the 10-question test

Short answer: score yourself on 10 questions across three things: buyer proof, your offer, and build readiness. Each line scores 0, 1 or 2, so the total is out of 20. Under 9, sell first: don’t spend a dollar on code yet. From 9 to 15, keep selling while you scope. From 16 up, you’ve earned the right to build. Most people land in “sell first”, and that’s the cheapest answer you’ll ever get.

Why this question matters more than the build

Building has never been easier. Which is exactly the problem.

You can get an app, a portal or an internal tool on screen in a weekend now. What you can’t get in a weekend is proof that anyone will pay for it, or use it. That’s the part that decides whether the money comes back.

None of these are tech problems. They’re decisions about what to sell, what to build and where to find customers. This test helps you make the first one.

There are three ways people get it wrong.

Problem 1: you’re building for a buyer you’ve imagined

You know the problem is real because you’ve felt it, or because people said “great idea!” when you told them. But “great idea!” is politeness. “Send me more info” is a soft no. “Let me know when it’s built” means it’s not a priority.

The fix: talk to real buyers about the last time the problem happened, before you touch the offer or the product. Ask about their past, not what they’d do one day.

Problem 2: people like it, but nobody has paid

You’ve had good conversations. People nod. Some even say they’d use it. But nobody has put money down, and you haven’t asked them to.

The fix: name the outcome and the price, then ask. Say the price out loud to a buyer. A yes that costs them nothing doesn’t count.

Problem 3: you have demand but no plan

Sometimes the buyers are real and some have paid. Then the risk moves from “will they buy?” to “will the build waste money?” Building everything they mentioned is how good demand turns into a big, slow, expensive project.

The fix: build only what someone has paid for. Write the smallest paid version on one page, deliver it by hand first, and set a budget ceiling before you talk to a developer.

The 10 questions

Score each line strictly. 2 = true today, with evidence. 1 = partly, or you think so. 0 = not yet.

If you’re a business owner building something for your own customers or staff, read “buyers” as the people who’d use it or sign it off. The owner version is in brackets.

A. Buyer proof (out of 8)

  1. I can name 10 specific buyers, people not companies, who have this problem. (Owner: 10 customers or staff by name who’d use it.)
  2. I’ve spoken to at least 5 of them about the problem in the last 60 days.
  3. At least 3 described the problem in their own words, without me leading them.
  4. They already spend money or time on a workaround: a tool, a person, a spreadsheet. (Owner: you can put a weekly cost on how it’s done now.)

B. Offer (out of 6)

  1. I can describe the outcome I sell in one sentence that a buyer would repeat.
  2. I have a price, and I’ve said it out loud to a buyer. (Owner: you know what it’s worth to the business each month.)
  3. At least one buyer has paid, pre-paid or signed a letter of intent. (Owner: someone with budget has signed off a trial.)

C. Build readiness (out of 6)

  1. I know the smallest version a buyer would pay for, and it fits on one page.
  2. I could deliver that version by hand, or with off-the-shelf tools, for the first 5 buyers.
  3. I have a build budget ceiling, and I know who will maintain it after launch.

Add it up. Your total is out of 20.

Your result

Find your band. Do the next step, not the next feature.

  • 0 to 8: sell first. Don’t spend a dollar on code yet. You don’t have enough buyer proof to know what to build. Any build now is a guess with a price tag. Next 14 days: 10 buyer conversations. Goal: 3 buyers who describe the problem in their own words.
  • 9 to 15: sell while you scope. You have signal, not proof. Buyers care, but nobody has put money down yet. Get 3 pre-sales or signed letters of intent at a real price. Write the smallest paid version on one page, and deliver it by hand first.
  • 16 to 20: build lean. You’ve earned the right to build. Pick your build path (no-code, AI-assisted, freelancer or agency) by risk and budget. Own your code, data and accounts from day one. Get a second opinion before you sign any dev quote.

Where you lost points is your next step

Look at your three subtotals. The lowest one tells you what to do this week.

  • Buyer proof low: you’re building for a buyer you’ve imagined. Talk to people before touching the offer or the product.
  • Offer low: buyers have the problem, but you haven’t asked them to pay. Name the outcome and the price, then ask.
  • Build readiness low: you’ve got demand but no plan. Scope the smallest paid version, and decide who maintains it.

What counts as proof

The test is strict on purpose. Here’s the line between signal and proof.

There are three levels: Talk. Commit. Pay.

  1. Talk: buyers describe the problem, what it costs them and what they’ve tried.
  2. Commit: they give you time, data, or an intro to the person who signs off.
  3. Pay: they pay for a small paid pilot before anything is built.

Only the third level earns a build budget. Four things count as a pre-sale: paid in full, paid a deposit, a signed letter of intent with a price, or time or data committed to a pilot. Likes, compliments and “keep me posted” don’t.

How to move up a band in 14 days

  1. Write down 10 names. Real people with the problem, not job titles. If you can’t get to 10, that’s your answer for now.
  2. Book 10 short calls. Twenty minutes each. Ask about the last time the problem happened, what it cost, and what they’ve tried. Keep your idea for the last five minutes.
  3. End every call with an ask. Every call ends with a yes, a no, or a referral.
  4. Say a price out loud. Offer to deliver the result by hand for a small group, at a real price, and ask if they want to be one of the first three.
  5. Count commitments, not compliments. After 10 calls, 3 or more real commitments means keep going. Fewer means change the buyer, the problem or the offer. Not the product.
  6. Take the test again. If you’ve moved up a band, the next step changes with you.

FAQ

I scored under 9. Does that mean my idea is bad? No. It means you don’t know yet. That’s a cheap thing to find out by talking to buyers, and an expensive thing to find out by building.

Can I build a quick prototype while I sell? A clickable mock-up to show buyers is fine. Building the real thing before anyone has paid is the guess with a price tag. If a buyer won’t pay for the manual version, they won’t pay for the app.

What if my buyers are my own staff, not customers? The same test works. Swap “paid” for “someone with budget has signed it off”, and “price” for what the problem costs the business each week. If nobody will put a number on it, wait.

I already have a developer quote. Should I just go ahead? Take the test first. If you score 16 or more, check the quote before you sign. If you score less, the quote can be perfect and the build still a waste.

How strict should I be? Very. “Not sure” scores 0. The only person you fool by scoring high is you.

The Build Case

Want a second opinion before you spend?

A business case, a build, buy or wait call, a one-page lean MVP scope, a plan to sell it first, and a check of one dev quote. US$1,500 (A$2,300 in Australia), fixed price, 2 weeks. Your fee comes off the 3-month community if you join.

I work with Sazae, a Sydney software and IT firm. If you need a build, I may suggest them, and you're always free to use your own developer.