Guide for nontechnical builders
Decide what your first app needs to prove.
Turn a broad idea into a short, testable brief before asking for screens and features.
01 — Describe one person and one task
Suppose you help a community group organize volunteer shifts. A useful first question might be whether a volunteer can find a suitable shift and understand how to express interest. That is smaller and easier to review than a full scheduling system with reminders, permissions and payroll.
- Describe what the person does today and what is difficult.
- Choose the action you want to make clearer or easier.
- Write down what you would observe if the first version worked.
02 — Walk through the journey on paper
For the volunteer example, sketch a shift list, shift details and an interest form. Give each screen one job. Use a few realistic sample shifts, including a full shift or an empty list, so the review covers more than a polished happy path.
- Name the starting screen and the next action.
- List the fields that are necessary for this test.
- Include an empty state and a failed-action state.
- Keep real personal information out of exploratory prompts and examples.
03 — Separate a demo from an operating service
Decide whether this version only demonstrates the journey or must save an actual request. A demo can show a clearly labeled example confirmation. An operating service needs a destination, appropriate access and a way to retrieve the request. Confirm these requirements before inviting real participants.
- Mark every sample-only action in the brief.
- List connections, permissions and publishing needs separately.
- Leave accounts, payments and reminders for later unless the first test depends on them.
- Ask for qualified help when the task involves sensitive information or complex access.
04 — Review the result against the brief
Use the worksheet below, then follow the product prompting guide to turn it into a build request. After generation, walk through the same journey and note what happened. For the volunteer example, a successful demo might mean a new visitor can find the right shift and understand the next step without an explanation from you.
- Ask someone unfamiliar with the idea to try the task.
- Record confusing steps before requesting more features.
- Make one focused change and repeat the same check.
- Expand the scope only when the first journey answers your original question.
A starting point
Make the brief specific.
Adapt this example to your business. Keep sample data separate from real customer information.
First-version scope worksheet Person using it: ___ Problem they face today: ___ One task they should complete: ___ Pages needed for that task: ___ Information shown or entered: ___ What happens after the main action: ___ What stays sample-only: ___ Features left for later: ___ The first version passes when I can observe: ___
When you need the next step
Follow the product documentation.
Before you start.
Do I need to choose a programming language first?
Start with the user, task, information and observable result. If an existing system or technical constraint determines the language or platform, include it in the brief and confirm it with the person responsible for that system.
How many features should a first version include?
Use the smallest set that lets you inspect one complete journey. There is no universal feature count. A feature belongs in the first version when the task cannot be tested meaningfully without it.
Find your next step.
Start with one useful task