Pre-Prompt Thinking Routine for Builders
Five minutes of thinking can save five hours of cleanup because debugging usually starts with a product mistake, not a syntax mistake.
Why five minutes matters
Builders often treat prompting like search. They type a goal, wait for code, and hope iteration will reveal the right product. That works for toy projects. It gets expensive once auth, billing, and state start interacting.
Amazon uses written memos before big meetings because writing exposes vague thinking. The same principle helps solo builders before a prompt.
The pre-prompt routine
Step one: write the user in one line. Step two: write the single action the app must help them complete. Step three: list the one thing users should feel after the flow works. Step four: name what you will not build today.
That is the whole pre prompt thinking routine. No slides. No mood boards. One page or less.
What to write down
Add three acceptance checks: what must work, what must never happen, and what would count as good enough for launch. Intercom grew by focusing on usable customer messaging flows, not by solving every support problem in one release.
Use real nouns. 'Freelance accountant uploads invoice PDFs' is better than 'users manage documents efficiently.'
How it changes debugging
When a build fails, you can compare the output to the routine. Did the app miss the user, miss the action, or ignore the exclusion list? Now you can correct the prompt without starting over.
The pre prompt thinking routine is tiny because it needs to happen every time.
Keep the pre prompt thinking routine near your editor. It makes AI tools feel less magical and far more useful.
Make structured thinking a habit.
Sparks trains quick framing, constraint-setting, and idea evaluation so your pre-prompt notes get clearer with each short session.
Download for iOS