Print or save as PDF: use your browser’s Print dialog.
Build personal software
like a product designer.
Six stages from problem to product. One page.
The problem usually isn’t your editor or model — it’s build before scope: momentum without legible work teammates can critique, align on, or reopen next month. The pain shows up as habits — skipping a written definition of done, polishing before structure, calling it finished before anyone else has clicked a path.
What this is: the same discipline strong product work uses, compressed into a repeatable path. You get concrete outputs per stage (not vibes). Slash commands are a convention in some tools; the order and artifacts transfer anywhere.
Using this map, you can:
- Share and critique without re-explaining the whole product each time.
- Align stakeholders on a real click path before engineering carries cost.
- Reopen the project later and still know where truth lives.
For depth — prompts and worked examples for all six stages — use the companion repo (same next step at the bottom of this page).
One next step: Get the full rules and prompts for every stage →
New project
/new-project
Benefit: Less “where did I put that?” next session — everything has a home before real work piles up. Do this: folders, naming, and a brief stub the later stages plug into.
Done when: Someone can open the project cold, see the problem/success placeholders, and orient in minutes — no tour required.
Product requirements
/prd
Write a short, measurable product requirements document: the problem you're solving, who it's for, the top 2–3 user stories, risks or constraints, and what success looks like with a testable signal. Keep it to one page.
Done when: You can answer "what are we building and why" in two sentences, you have acceptance criteria you could actually check, and scope is bounded enough to spot creep.
Lo-fi wireframes
/lofi
Benefit: Cheap experiments — structure changes don’t cost a redesign. Do this: ASCII boxes, labels, arrows for IA and the primary journey; no pixels or components yet.
Done when: Main screens exist as ASCII, the happy path is walkable end-to-end, and decision points read clearly without design context.
Mid-fi
/midfi
Lock design decisions before polish: spacing tokens, type scale, color roles, component inventory, interactive states, and keyboard/focus behavior. Produce a unified UI overview that captures these decisions in one place.
Done when: A developer could implement the component set from what's specified, no design decision is left implicit, and the hi-fi pass has nothing fundamental left to figure out.
UI prototype
/ui-proto
Benefit: Surprises show up in a click path before they’re expensive — not in a late engineering review. Do this: clickable primary flow (e.g. Tailwind + shadcn-style components).
Done when: The main flow demos without you talking over it, edge cases are named (even if stubbed), and at least one person who didn’t build it has clicked through.
Hi-fi + handoff
/hifi
Produce the design kit and a screen gallery for engineering handoff: polished components, annotated edge cases, spacing and token notes, and a handoff brief so the next person isn't starting from scratch.
Done when: An engineer can implement without a standing design meeting, every state is documented, and the artifact survives you being unavailable for a week.
What to remember (rule of one path)
- —Problems before pixels. You’re not buying speed — you’re buying clarity. Name the job-to-be-done and “done enough” before the tool opens.
- —One stage, one artifact. Lo-fi waits for a scoped PRD; mid-fi waits for a walkable lo-fi flow — so you rebuild less.
- —AI speeds hands; it doesn’t replace judgment. The bottleneck is “what to build and why” — spend your attention there.
- —If it needs a live tour, it’s not done. Artifacts are for reviewers, stakeholders, and future you.
- —Prove one thin slice first. One honest flow beats a broad build that never ships.