Most builders still think the hard part is coding.
That used to be true. It isn’t anymore.
Today, with AI tools, templates, and vibe coding workflows, a single person can build in days what used to take a small team weeks. That sounds like good news, and it is. But it changes the game. When software becomes easier to produce, the real bottleneck moves upstream.
The scarce skill is no longer just execution. It is judgment.
That is the core idea behind What to Code: in a world where almost anything can be built, the real advantage comes from choosing the right thing to build.
The book makes a simple but powerful point: most projects fail long before launch, not because the code is bad, but because the premise is weak. Builders fall in love with elegant solutions, trendy categories, or new technical capabilities, then go looking for a problem to attach them to. That is backwards.
Pain is the Way
A better approach is to start with pain.
Not vague dissatisfaction. Not “people want to be more productive.” Real pain. Repeated pain. Costly pain. The kind that already shows up in workarounds, spreadsheets, manual cleanup, delays, mistakes, or quiet frustration that someone has learned to tolerate because there is no better option.
That is where good software opportunities usually come from.
One of the most useful ideas in the book is that strong opportunities tend to have four traits:
- the problem is real,
- it happens repeatedly,
- the affected users are reachable, and
- the builder has some meaningful fit with the space.
That fit matters more than most people think. The same idea can be great for one founder and terrible for another, depending on access, trust, domain knowledge, and distribution.
The Money is in the Niche
Another big takeaway: specificity beats breadth.
Broad ideas sound exciting. “AI for small business operations” sounds bigger than “a tool that catches missing attachments before insurance claims are submitted.” But broadness usually hides weak urgency. Specificity is what makes products adoptable. A concrete problem in a real workflow is easier to explain, easier to test, easier to sell, and easier to improve.
The book is also strong on validation. Demand is not praise. It is not likes, compliments, or “that sounds useful.” Demand is behavior. Do people try it? Come back? Change their workflow? Pay? Recommend it? If not, the signal is weak, no matter how encouraging the conversation felt.
Automate the … Boring Stuff?
The deepest lesson is probably this: boring problems are underrated.
A lot of money is hiding in ugly workflows — invoicing, approvals, claims, scheduling, reporting, reconciliation, handoffs, compliance checks, repetitive admin. These problems are not glamorous, but they are expensive. And expensive, recurring friction is exactly where small software businesses become real businesses.
What to Code — the practical summary
The book’s core argument is simple: in a world where building software is getting easier, the main advantage is no longer raw execution speed. The advantage is choosing a problem that is painful, repeated, reachable, and close enough to your own edge that you can actually solve and sell it. The mistake most builders make is starting with an idea, a tool, or a capability. A better process is to start with a recurring cost in the real world: wasted time, repeated errors, messy handoffs, manual cleanup, delayed billing, unclear approvals, or ugly workarounds people tolerate because nothing better exists.
The useful filter
| Question | Strong signal | Weak signal |
|---|---|---|
| Is the problem real? | People already complain, workaround it, or waste time on it weekly | People say it “sounds useful” |
| Is it repeated? | Daily or weekly pain | Rare or one-off pain |
| Is it costly? | Time, money, delays, mistakes, compliance risk | Mild convenience issue |
| Are users reachable? | You know where they are and how to talk to them | “Everyone” is the user |
| Does it fit existing workflow? | Slots into something they already do | Requires a whole new habit |
| Is software the right fix? | Repetition, routing, data cleanup, search, classification | Mostly cultural or political problem |
| Do you have builder fit? | Domain knowledge, trust, access, distribution, patience | No edge, no access, no credibility |
| Can you test fast? | You can get real behavior in days | You need months to learn anything |
This is basically the book’s opportunity lens: real pain, repeated need, reachable users, right builder. If one of those is missing, the idea may still be interesting, but it is probably weak.
What to look for in the wild
The best software ideas often hide inside boring operational friction:
| Look for this | Why it matters |
|---|---|
| A spreadsheet that “shouldn’t exist” | It often means the official workflow is broken |
| A task someone does “every time” | Repetition is where software wins |
| A process held together by one careful person | That is human glue covering system weakness |
| Delays before billing, approvals, or handoffs | Time lag often has direct monetary cost |
| Re-entering data across tools | Translation work is classic automation territory |
| Repeated manual checks | Good target for software-assisted validation |
| Teams exporting from one system just to work in another | Strong sign of poor workflow fit |
The book makes an important distinction here: broad ideas sound exciting, but specificity beats breadth. “AI for small business ops” is vague. “A tool for bookkeeping firms that extracts invoice fields from emailed PDFs into the review queue” is specific enough to test, explain, and sell.
The behavior test
The clearest lesson in the manuscript is that demand is behavior, not praise.
| What people say | What it usually means |
|---|---|
| “Cool idea” | Very weak signal |
| “I’d use that” | Still weak |
| “Can you show me?” | Better |
| “Can I try it on my real data?” | Strong |
| “Can this fit into our workflow?” | Very strong |
| “How much?” | Strong buying signal |
| “This would save us every week” | Excellent |
| They come back and use it again | Best signal |
The best one-sentence takeaway
Do not ask, “What could I build?”
Ask, “What costly, repeated friction can I remove for people I can actually reach?”
A practical next step
Take your top 3 ideas and score each one from 1–5 on:
- severity,
- frequency,
- measurable cost,
- reachability,
- software fit,
- existing workaround evidence,
- willingness to act/pay,
- specificity,
- builder fit,
- speed to useful test.
Then kill the weakest one immediately.
Conclusion
If you build software, this book gives you a much better filter for deciding what deserves your time. It pushes you away from random idea generation and toward observed reality, where the best opportunities usually hide.
If that sounds useful, you can get the full book here: What to Code on Amazon
