Build/Build & digital tools
Build a tiny app for one recurring annoyance
Turn one everyday problem into a focused interface, data model, and build prompt.
Here’s what it could look like.
An illustrative example to show the direction. Your details will make it different.
Two people keep a list of restaurants but cannot choose dinner. Sample places: Cedar Bowl—quick, vegetarian options; Harbor Noodles—casual; Finch Table—special occasion. No accounts, live availability, delivery ordering, or maps in the first prototype.
PRIMARY FLOW Choose a mood → see three saved places → pick one or request another shortlist. SCREENS Tonight: mood choices and a shortlist. Saved places: add or edit a place. DATA ID, name, user-entered tags, neighborhood, notes, last chosen date. ACCEPTANCE Every suggestion comes from the saved list. An empty list leads directly to Add place. A one-place list never pretends there are alternatives. The same place cannot occupy multiple shortlist positions. PERSISTENCE Prototype data can be kept in the browser; explain that it is not synced across devices. BUILD PROMPT Create a responsive prototype of this flow with the supplied synthetic records, readable cards, and visible selection state. Keep all external integrations out of scope.
A good way to get there.
- 01
Describe one recurring decision or action and the current workaround.
- 02
Write the smallest useful flow with real sample data and clear empty/error states.
- 03
Ask for a build brief and an initial prototype using synthetic data.
- 04
Test the core action before adding accounts, integrations, or remote storage.
The prompt behind this idea
Replace the bracketed details or make it yours using the form.
Design a tiny app for [Add problem], used by [Add users]. Sample data: [Add data]. Out of scope: [Add limits]. Define one primary user goal, the smallest set of screens, data fields, interactions, and acceptance criteria. Include empty, loading, and failure states where relevant. Start with synthetic or local data and state persistence limits honestly. Do not pretend to connect services or deploy. Produce a focused build prompt and list the decisions that must be made before real personal data is stored.
Give it a second look.
- The prototype solves one recurring problem.
- Every visible action has honest behavior.
- Empty and small-data states are specified.
“Cut the scope by half while preserving the dinner-choice moment. Identify what can be removed from the first screen.”
A generated build brief is not a security review or a production deployment.
The capability to look for
A coding assistant or artifact environment; the result still needs to run and be checked.
Find a tool for the jobHow these ideas and prompts are made