An easy way to build apps with AI. Minus the guesswork.
A four-step framework for the people who use software every day but rarely build it. State what it does. Plan inputs and outputs. Examine edge cases. Check it works.
The problem SPEC solves
AI assistants are excellent at writing code. They're not excellent at reading your mind. When you're vague, they guess. Their guesses become the tool you get back.
The hard part isn't getting code anymore.
Four short answers, in plain English, written before you generate any code. SPEC is the smallest amount of structure that meaningfully improves what AI builds for you.
The method
The method moves from abstract to concrete, then closes with verification. Each step does work the others don't. Skip one and you'll feel the gap when you try to build.
Step 1 of 4
One to three sentences. What the tool is, and what it accomplishes. Capture the concept. Not how it works — just what it is, and what it does for you.
If you can read your S aloud and someone else can't picture the tool, it's not specific enough yet. Refine until they can.
Step 2 of 4
The normal interaction. What goes in, what comes out. Specific values, options, and defaults matter. If your tool has options, name them. If it has defaults, state them. The AI won't know your preferences if you don't say them. Be concrete enough that someone could mock it up without asking you questions.
Describe what the tool does, not how it looks. Leave visual choices to the AI unless you have a strong preference.
Step 3 of 4
The unusual moments. What the tool does at the boundaries.
Empty inputs. Refreshing the page. Switching modes. Unexpected values. Plus any preferences you have that aren't visible in the inputs and outputs. Four kinds of things go here:
You don't have to describe everything that could go wrong. Just the moments where you have a preference about what should happen.
Step 4 of 4
The verification. How you'll know your app is done and working as expected.
A short list of things to do with the tool, paired with what should happen. Each check is plain English, concrete, and observable.
Each check should use the same shape: "When [action], [result]."
When an unsupported file is uploaded, an error message reminds me about the types that can be used.
This format does three jobs at once:
The tool
Write your four answers. Get a clean markdown prompt to paste into any AI assistant. Your work is saved automatically in your browser.
Step 1 — S
One to three sentences. What is this app? What does it accomplish?
Step 2 — P
What goes in. What comes out. Specific values, options, and defaults that matter.
Step 3 — E
Unusual inputs. State transitions. Errors. Non-functional preferences. One per line.
Step 4 — C
Use the shape: When [action], [result]. One per line.
From SPEC to prompt
Your SPEC is the thinking. The prompt is the same content with markdown headings the AI can read at a glance.
The ## marks are titles in markdown. Every AI assistant reads them natively. The single # is left free for when you split a bigger tool into pieces.
Once you've written your SPEC, the prompt is essentially ready. You're translating field names, not rewriting content.
// the prompt template ## What it does [your S] ## Inputs and outputs [your P] ## Edge cases - [your E] ## Checks - [your C]
Going bigger
Most personal tools fit in a single SPEC. Bigger ones — with several views, distinct features, or workflows that span multiple screens — should be split.
A parent SPEC describes the whole app. Each child SPEC describes one piece, using the same four steps you already know. Same method. Used more than once.
In the prompt, use a single # to name each piece of the app, and ## for the four sections inside each piece. The structure does the rest and works the same inside each one. Past three or four pieces, you are starting to outgrow the single-file zone and should consider different methods.
Questions
The SPEC Method is a four-step framework for using AI assistants to build software. The steps are: State what it does, Plan inputs and outputs, Examine edge cases, and Check it works. It's the smallest amount of structure that meaningfully improves what AI builds for you.
People who use software every day but rarely build it: product managers, consultants, operations leaders, business analysts, founders, marketers. Anyone whose work runs on judgment, documents, and decisions, and who wants to use AI to build their own tools without learning to be a software engineer.
Prompt engineering tries to find the right magic phrasing. The SPEC Method ignores phrasing and focuses on substance: the four kinds of information the AI needs before it can build the right thing. Once you have your SPEC, the prompt almost writes itself.
No. The SPEC Method is designed for people who don't write code for a living. You write the four answers in plain English. The AI writes the code. You verify it does what you specified.
All of them. The SPEC Method produces a structured plain-English prompt that any modern AI assistant reads natively — ChatGPT, Claude, Gemini, others. Free versions are sufficient. Different assistants produce visually different tools from the same SPEC, and that variation is normal.
Because the method doesn't depend on any specific tool's features, your SPECs survive model upgrades and tool changes.
Frameworks like GitHub Spec Kit and Kiro are built for engineering teams shipping production software. They assume codebase context, CI/CD integration, and an engineering background.
The SPEC Method is the lightweight cousin: same family of ideas, sized for one person building one small tool in an afternoon.
For apps with multiple screens or features, write a parent SPEC for the whole tool and a child SPEC for each major piece. Same four steps, used more than once. Past that, you've outgrown the personal-tool zone and need different approaches.
All four fields and your prompt options will be reset. This can't be undone.