The struggle

Support asks for it every month. It would take an engineer two days. It has never once beaten anything else on the roadmap, and it never will, because the honest comparison is two days of engineering against revenue, and internal convenience loses that comparison forever. So you decline it again, and the team keeps doing the thing by hand.

The obvious fix — “just prioritise it” — doesn’t fail because your team is unreasonable. It fails because it’s correctly prioritised. It genuinely is worth less than the roadmap items above it. It’s simply also worth more than zero, which is what it gets.

The other obvious fix — build a prototype — misses too. A prototype doesn’t solve this; it produces a demo of the solution and then still needs an engineer to build the real one. What changed recently is that for a narrow class of software — internal, few users, no revenue at risk, no customer data — the thing you build is the real one. That class is bigger than most PMs realise, and shipping into it is the highest-leverage thing on this site.

The chain

Step 1 — Pick something that genuinely cannot hurt anyone

This step decides whether the rest is sensible or reckless, so be strict. Good first candidates: a dashboard over a CSV export, a form that writes to a spreadsheet, a lookup tool over data your team already has, a script that reformats a weekly report.

Disqualifiers, any one of which ends it: it touches customer data, it writes to a production system, it needs real authentication, it would embarrass you if it were wrong for a week, or it’s the kind of thing someone would quietly come to depend on for a decision that matters. “Internal” is not a synonym for “safe” — it just narrows the blast radius.

Write down who the five users are. If you can’t name them, it isn’t the right first project.

Step 2 — Set the context before you build · Claude Code

Install Claude Code (curl -fsSL https://claude.ai/install.sh | bash on macOS, Linux or WSL — but check the docs for the current line). Make an empty folder, and before asking for anything, write a short CLAUDE.md: what the tool is for, who uses it, what it must never do, and the constraint that matters most (“one HTML file, no build step, no server”).

Skipping this is the most common way these projects go wrong. Without it, session two happily rearchitects what session one built, and you have no idea why.

Step 3 — Build the thinnest version that’s genuinely useful

Describe the tool and ask for the smallest thing that works. Then look at it, and correct it. That loop is the entire skill:

Build the smallest working version of this tool:

WHAT IT DOES: <one sentence>
WHO USES IT: <the five people, and what they do with it>
INPUT: <the CSV / the sheet / the API — be specific about the columns>
OUTPUT: <what they see, and what they do next>

Constraints:
- Smallest thing that works. No auth, no database, no framework unless I ask.
- One file if possible.
- Where you had to guess something I didn't specify, list those guesses at the
  end under ASSUMPTIONS. Don't bury them in comments.
- If what I've asked for is a bad idea, or genuinely needs a real engineer, say
  so before you build it rather than building it anyway.

Then tell me exactly how to run it.

The ASSUMPTIONS list is the load-bearing part. It’s where you find out it decided your dates were US-format, or that it invented a status field you don’t have. Read that list before you read the code.

Honest trade-off: if you want the thing hosted at a URL with no local setup — because your five users won’t install anything — Replit Agent is the better starting surface. You trade editing precision for the deploy problem disappearing, which for a first project is often the right trade.

Step 4 — Put it in front of one real user, then stop

Show it to one of your five. Watch them use it without helping. Fix the two things that made them hesitate. Then stop building and let it sit for a week.

The failure mode here isn’t a bad tool, it’s scope: it works, so you add a feature, then another, and you’ve quietly created an unmaintained internal system with one owner who has a different day job. A tool that does one thing and is finished is the win.

Step 5 — Tell your engineers what you did

Not for permission — for two reasons that are both in your interest. First, someone should know it exists, so it doesn’t become an unowned dependency discovered during an incident. Second, it changes what you’re allowed to ask for next: a PM who has shipped something, however small, argues about effort estimates from a different position.

Where it breaks

Scope creep into something load-bearing. The real risk, and it’s gradual. A tool five people use for convenience becomes a tool forty people use for decisions. The moment that happens it needs an owner who isn’t you — hand it over or turn it off.
Confident, fast wrongness. An agent doesn’t refuse when it’s out of its depth; it produces something plausible at speed. On a codebase you don’t understand you have no way to notice. This is exactly why step 1’s restrictions aren’t optional.
Security assumed rather than checked. No auth is fine for a local script and not fine for something on a URL. If it ends up hosted, someone who knows what they’re doing needs to look at it before it holds anything sensitive.
Silent data errors. The tool renders a number; nobody checks the number. Verify the first week’s output against the manual process it replaced before anyone trusts it.
Cost drift. Claude Code bills on token consumption, and long unfocused sessions are the expensive kind — Anthropic’s cost docs put enterprise usage at ~$13 per developer per active day. Clear between tasks.
Thinking this makes you an engineer. It doesn’t, and pretending otherwise is how the first three failure modes happen. It makes you someone who can ship a narrow class of small things — which is genuinely valuable, and a much better claim to defend.

“The thing your support team asks for every month is two days of engineering work, and it has been sitting at position fourteen on the roadmap for a year.”