Build your first real tool, from idea to working app

headless, my content-operations console, started as one question: why am I paying six tools to not understand my work? This is the path from that question to a working app, in the order I'd do it again.

Write the problem as a job, not a feature list

Start with the job you do by hand today, step by step:

Every morning I check ~20 AI and VFX sources, decide what matters to me, read the important ones properly, and turn one into a LinkedIn post in my voice.

Each step becomes a module: collect → label → explain → draft. If you can't describe the manual version, you're not ready to automate it.

Pick boring, local technology

Ask Claude for a stack you can run on your own laptop, with no servers or accounts:

Propose the simplest stack for a local web app with a small database, that I can run with one command. Explain each choice in one line.

For headless that was a web framework (Next.js), a database that's just a file (SQLite), and a button that starts each job. Boring is good. You're here to build the thing, not the infrastructure.

Build one thin slice end to end

Don't build all the modules halfway. Build one all the way through:

1. Fetch one source
2. Save the items
3. Show them in a list
4. Add one AI step: label each item for relevance to me

Once one slice works, the rest is repetition. headless now reads 19 sources. The first version read one.

Give the AI steps a brief

Every AI feature is a mini brief. Write it the way you'd brief a junior:

For each item, return: a category, a 0–100 relevance score for a VFX supervisor building AI tools, and one line on why. Be strict: most things are not relevant.

Ask for structured output: named fields, not paragraphs. That's what makes results sortable, filterable and cheap to check.

Put your taste in files, not prompts

My LinkedIn drafts sound like me because the agent reads two things before every draft: a style guide I edit by hand, and a list of my own real posts as examples. Keep both as files in the project, so they're versioned, editable and shared by every feature.

For rules that must never break, use code, not prompts. A prompt can ask for no em dashes and a 3,000-character limit. A small function guarantees it.

Make every job manual first

Every job in headless started as a button, not a schedule. Automate only after you've watched a job run by hand enough times to trust it, and after you know what it costs (next playbook).

Keep a handover doc

Ask Claude to maintain a HANDOVER.md: what works, what's broken, what's next, and every decision with its reason. Long projects span many sessions. The handover is how the next session, or future you, picks up without re-explaining.

Update HANDOVER.md with what we built today, what's still broken, and the next three tasks.

Build checklist

1. The manual job written down, step by step
2. The simplest local stack, explained
3. One vertical slice working end to end
4. AI steps with briefs and structured output
5. Taste in files; hard rules in code
6. Manual buttons before schedules
7. A HANDOVER.md kept current