Ship an internal tool

Step 1 — Name the chore, not the app

Don’t start with “I want an app.” Start with the ritual: the numbers you copy between spreadsheets every Friday, the status report you assemble from four places, the list you check by hand. The test: it recurs at least weekly, it follows rules you could explain to a new hire, and it annoys you. Then:

Here is a chore I do repeatedly, start to finish: [describe every click and copy-paste]. Ask me questions until you fully understand it. Then propose the SMALLEST possible tool that eliminates it — three features maximum. What would version one refuse to do?

“Smallest” is load-bearing. The version waiting in a backlog has twenty features; the version that ships today needs three.

Step 2 — Spec it into a folder

Make a fresh folder for the project — this is a folder as a project: the spec, the data, and the journal all live where any future window can find them. Have the chat write plan.md into your notes, then save it there: the chore, the three features, what goes in, what comes out, and what version one refuses to do.

Step 3 — Fake data first

Before anything gets built:

Generate a realistic fake dataset matching the real one I’ll eventually use: same columns, same messiness — [describe the shape: names, dates, amounts, the weird edge cases yours has]. Save it as sample-data.csv.

The rule, stated plainly: no real customer, financial, or personal data enters this project until the tool is finished and access is sorted. Fake data is freedom — you can test hard, share the URL, and break things in public, because there is nothing in it to protect.

Step 4 — Give it hands

Open a terminal in the folder and start Claude Code:

Read plan.md and sample-data.csv. Build this tool as a simple web app. Set up a git repository, commit as you go, and show me how to run it locally.

You don’t need to read the code — the command line is the same window with hands, and the repo is your undo button. When something’s wrong, describe it, don’t debug it: “the totals are wrong when a row has no date” is a perfect instruction.

Step 5 — Inspect like your most careless coworker

This is the INSPECT step of the method, and it’s where internal tools are won. Use the tool the way the least careful person on your team will: empty input. The wrong file. A huge file. Clicking submit twice. A phone screen. Every flub you find, describe it and rerun — you’re not reading code, you’re breaking the tool while breaking it is free.

Step 6 — Ship it, and draw the line

Create a private GitHub repository, push the project, and deploy it to Vercel. Give me the live URL.

Send the URL to one teammate with the fake data still in it. Then draw the line, in writing — have it add this to the repo’s README:

⚠️ Running on SAMPLE DATA. Before any real data enters this tool, it needs real access control. That is a separate piece of work, and it happens first.

A deployed URL is reachable by anyone who has it. With fake data, that’s fine — that’s why Step 3 exists. The day the tool earns real data is the day you stop and add a lock first; future-you will thank the README for refusing to let the shortcut happen.

From here it’s the living loop: a teammate asks for a change, you open the folder, start a fresh session, describe it, commit, deploy. The backlog never finds out.

---

Check your understanding: why does fake data come before the first line of code — and where exactly is the line before real data goes in?

Use this process for other small tools. Chore → smallest tool → fake data → break it → ship behind the line. That’s the report generator, the form filler, the list checker, the little dashboard — every “someone should really build us a…” your team has said out loud.