Next week you're going to discover something dangerous. And it’s going to be thrilling.
AI building tools are so powerful now that you can add features as fast as you can think of them. "What if it also..." becomes "Wait, I'll just add..."
One minute you're building a simple invoice processor. Next minute it has user accounts, team collaboration, and a built-in CRM. Because sod it, why not? The AI can build it all! Let’s go go go!
This is the vibe coding trap. When building becomes effortless, scope creep happens at light speed.
I've watched developers go from a sensible business idea like a "PDF to spreadsheet converter" to "full collaborative document management platform" in a single afternoon. Not because they planned it. Because they could.
That's why today we're doing something boring but crucial: creating your build specification.
This isn't just busy work. You know I hate pointless effort. No, this is your protection against yourself.
Let's get started:
When you see what Lovable, Cursor, and Bolt can do next week, you'll want to build everything. The AI will encourage you. "Sure, I can add that!" it'll say. "Want user authentication too? Let’s do it baby!"
It’s intoxicating. And dangerous.
Because nothing will get finished.
No. Instead you want what's in your spec. Nothing more.
A good spec isn't just a technical document. It's a promise to yourself about what you will and won't build. It's the difference between shipping in a week and getting lost in endless features… a very common problem when people start vibe coding as we will next week.
Your spec needs five things:
The User Journey: Start to finish, what does the user do? They arrive at your tool. They input X. They wait Y seconds. They receive Z. They leave happy. Map every step, even the obvious ones.
Technical Flow: Your Input → Process → Output from Day 13, but with more detail. What format is the input? What exactly does the AI do? What format is the output? How is it delivered?
Design Decisions: Not "make it pretty" but "one button that says Process" or "results appear below the input." Simple, specific choices. No animations. No fancy layouts. Just functional.
Success Criteria: How do you know it works? "Processes invoice in under 30 seconds" or "Extracts all email addresses from document" or "Summary is under 200 words." Measurable outcomes.
The NOT List: Equally important. NOT doing user accounts. NOT adding payment processing (yet). NOT building an API. NOT creating a mobile version. This list saves you from yourself. If anything this is more important than the to-do list. With AI we can do pretty much everything. Doesn’t mean we should!
A lot here but don’t worry. I’ve built out a prompt for you.
Let’s turn our winning MVP idea into a buildable blueprint:
You are a build specification expert. Create a focused, one-page spec for this MVP that prevents scope creep and enables rapid building.
My chosen MVP:
[Insert your winner from yesterday with Input → Process → Output]
Target users: [Who specifically will use this]
Core problem it solves: [From your research]
Create a build specification with:
1. USER JOURNEY
- Step-by-step flow from landing to result
- Exactly what user sees/does at each step
- Where they might get confused
- How they know it worked
2. TECHNICAL FLOW
- Input: Format, size limits, validation needed
- Processing: Exact AI transformation
- Output: Format, delivery method
- Error handling: What if something goes wrong
3. DESIGN DECISIONS
- Page layout (simple)
- Button text and placement
- Where results appear
- Colour scheme (just pick one)
- Font (just pick one)
4. SUCCESS CRITERIA
- How fast must it work?
- What defines a successful output?
- How will you test it works?
5. NOT DOING LIST
- Features to explicitly exclude
- Complexity to avoid
- Future ideas to ignore (for now)
Keep it under one page. Make it so clear that someone could build this without asking any questions.
This feels tedious. It is tedious. That's the point. Sorry!
Every boring decision you make today is a rabbit hole you avoid next week. Every feature you explicitly exclude is an hour saved. Every success criterion is a shipped product instead of endless tweaking.
Basically your current self is protecting future self from getting overexcited.
Next week, when the AI suggests adding "just one more feature," you'll check your spec. Not included? Not building it.
When you're tempted to "improve" the design, you'll check your spec. Already decided? Move on. When you wonder if it's "good enough," you'll check your success criteria. Met them? Ship it.
The spec isn't fun. But shipping is. And specs lead to shipping.
By end of today:
One page. No ambiguity. Ready to build next week.
Share your commitment:
"Day 15 of AI Summer Camp: Created my build spec.
Building: [Your MVP name] Input: [What users provide] Output: [What they receive]
More importantly here is what I’m NOT building: user accounts, payment processing, mobile app, API, or anything else that would delay shipping.
That comes later!
Spec done. Building starts Monday."