Framework: Don't design for the product you wish existed

Open Beginner friendly
#3 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Quiet
Domain
ai, documentation

Research direction

Start by reviewing the suggested locations, frameworks/ai-era-practices/design-for-shipped-capability.md and frameworks/execution/. Add the framework sections for symptoms, causes, the real-data-only prompt, the review checklist, and preserving future vision work. Done means the guidance clearly distinguishes shipped capabilities from roadmap ideas and includes the Balance case study.

Written by the indexing model from the issue text.

Description

Summary

Add a framework about the recurring anti-pattern where AI design tools (Claude Design, v0, etc.) produce mockups that imply capabilities the backend doesn't have. The fix is an explicit "real data only" directive at the start of each design round + a verification step when reviewing results.

The problem

AI design tools fill gaps to make things feel complete. A mockup showing "Gig Detail" will invent:

  • Shift schedules ("Thu / Fri / Sat nights") — if your data doesn't track schedules
  • Per-shift predictions ("Next shift: Tonight 5–11pm, est $400") — if you only have aggregated paydays
  • Collision detection ("Rent hits before your deposit clears") — if you don't have expense tracking
  • Actionable features ("Move rent to May 2") — if you can't reschedule expenses

All fabricated. All would need months of backend work to ship. None flagged in the design.

Proposed content

  • Symptoms — what fabricated-data mockups look like
  • Why it happens — LLMs complete patterns; designs feel "finished" only when fields are full
  • The prompt template that prevents it — explicit "real data only" directive with a list of "intentionally NOT present" items
  • The review-checklist that catches it post-hoc — per-field audit: does this capability exist today, or is it roadmap?
  • How to preserve the aspirational work — don't throw it away; move to a clearly-labeled "Future vision" track for fundraising/roadmap conversations

Case study

Balance's three Claude Design rounds in April 2026 all kept producing fabricated schedules, collision detection, and shift-availability APIs until an explicit "real data only" directive was added to round 4's prompt. Round 4's output included an explicit code comment: "Intentionally NOT present: per-shift predictions, gig schedules, rent, recurring expenses, collision detection, shift-pickup APIs. Those are roadmap."

Suggested location

frameworks/ai-era-practices/design-for-shipped-capability.md or frameworks/execution/

Source

Balance design review rounds, 2026-04-19

Dominant language
Shell
Stars
4
Forks
2
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from breethomas/bette

All issues in breethomas/bette

Similar issues

More Shell/Bash issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.