LULUSKILL ARTICLE
From a prompt to a first version: pages, data, permissions and the key flow
How to decide, on paper, the four things every first version needs — and how to write them into a one-page plan before anything is built.
This is LuluSkill's own writing. It does not quote, mirror or summarise any third-party Skill, and it recommends none. Reading it builds, publishes and runs nothing: what an AI tool does with your text is for you to check.
A first version is one finished flow, not a small copy of everything
A common picture of a first version is the whole idea with every part done a little. That version rarely works, because every part is half-finished and none of them can be checked. A more useful picture is one path, from arrival to result, that works completely for one kind of person.
Once that path is chosen, four decisions follow from it: which pages the path passes through, which information it has to keep, who is allowed to do each step, and what the path looks like when something goes wrong. Deciding them before you ask anyone to build is what turns a prompt into a plan.
You may have heard this called a minimum viable product, or MVP. The name matters less than the test: a first version is small enough when one kind of person can finish one job with it, and nothing on the plan exists only because it might be useful later.
A first version is ready to plan when
- You can name the one kind of person it is for.
- You can describe their path in five steps or fewer.
- You have a written list of what is deliberately left out.
Pages: list only the screens the path passes through
Walk the path and write down every screen the person sees, in order. That list is the first version's page list. A page that is not on the path — an "About" page, a settings page, an admin dashboard — goes on the later list unless the path cannot finish without it.
For each page, write three lines
- What the person came to this page to do, in one sentence.
- What they must see to do it — the minimum, not everything that could be shown.
- Where they go next, including where they go when they change their mind.
States a page usually forgets
- Empty: what the page says before there is anything to show.
- Waiting: what the person sees while something is still loading or being saved.
- Failed: what the page says when saving did not work, and what the person can do about it.
- Done: how the person knows, without guessing, that the step is complete.
Data: decide what is kept, for how long, and whose it is
Every piece of information a first version keeps is a promise: that it will still be there tomorrow, that the wrong person will not see it, and that it can be removed if someone asks. Fewer pieces means fewer promises. For each one, write down why the path needs it — and remove it if the answer is "it might be useful".
Four questions for each piece of information
In plain words
- What is it?
- A plain name and an example value you invent: "shift date, such as the first Saturday of the month".
- Whose is it?
- The person it describes or who entered it. If it describes someone else, it is personal information and needs extra care.
- How long is it kept?
- Until the event is over, until the person deletes it, or for a fixed period. "Forever" is a decision too, and rarely the right one.
- What if it is wrong?
- Who can correct it, and what happens to anything that already relied on the wrong value.
Information to keep out of a first version
- Passwords you would have to store yourself, if a simpler way to recognise people is enough for now.
- Payment card details, identity numbers and health information, unless the whole point of the product is to handle them properly.
- Anything collected "for analytics later" that the path does not use today.
Permissions: who may see, change and remove each thing
Permissions sound technical, but on paper they are a small grid: the kinds of people down one side, the pieces of information across the top, and in each box one of "see", "change", "remove" or nothing. Start every box at nothing and add only what the path needs. It is much easier to grant something later than to take it back.
Fill the grid in this order
- List the kinds of people, including someone who is not signed in at all.
- For each kind, mark only what the path requires them to see.
- Then mark what they must be able to change — usually only their own entries.
- Finally, decide who may remove things, and whether removal can be undone.
Permissions for the tool itself
- If an assistant or a local tool will work on your computer, the same rule applies to it: name the folders it may read, the ones it may change, and assume everything else is off limits.
- Deleting files, sending messages on your behalf and reaching the internet are separate permissions. Grant each one only when a step needs it, and only for that step.
The key flow: the one path that must work end to end
The key flow is the path from the first section, now written as numbered steps with what the person does and what they see back. It is also your acceptance check: if a friend can follow it without your help and reach the result, the first version does its job. If they cannot, nothing else on the plan matters yet.
Write down three versions of the flow
- The ordinary path, where everything goes as expected.
- The path where the person makes a mistake — a wrong date, a missing field — and how they recover.
- The path where something outside their control fails — no connection, a full list — and what they are told.
Putting it together: a one-page plan
Example
An invented plan for a community garden's tool-lending list, written before anything is built.
- For: garden members borrowing shared tools on weekends. Shape: a web app, because each member needs to see what they have borrowed.
- Pages: the tool list, one tool's page with a "borrow" action, and "my borrowed tools". Each has an empty, waiting, failed and done state.
- Data: each tool's name and whether it is out; each loan's member, tool and date. Loans are removed a month after return. No phone numbers.
- Permissions: visitors see nothing; members see the tool list and their own loans; one coordinator can mark a tool returned.
- Key flow: a member opens the list, picks a free tool, borrows it, and sees it under "my borrowed tools". If the tool was taken a moment earlier, they are told so and nothing is saved.
- Out of scope: reminders, reservations in advance, damage reports, and a public page.
The whole plan fits on one page, and every line is a decision a reader can disagree with. That is what makes it useful to hand to someone — or to an assistant — and what makes the result checkable when it comes back.
Before you hand the plan to anyone, check that
- Every page on the list appears somewhere in the key flow.
- Every piece of information names whose it is and when it is removed.
- Every filled box in the permissions grid has a step that needs it.
- The mistake path and the failure path both end with a message the person can act on.
- The out-of-scope list names at least two things you are choosing not to build yet.
What the garden plan produced, and what it left out
A plan is not a prediction. The useful question after a first version comes back is not "did it match the plan", but "which line of the plan did this result answer, and which line was never decided". The two produce different next steps: the first is a fix, the second is a paragraph you still have to write.
The example below continues the invented community garden. Everything in it is invented for this article, including what came back; it is written to show a comparison being made line by line, not to describe any real result.
The first version, read against the plan
Example
Four lines of the one-page plan, and what each one turned out to mean in practice.
- Pages: the tool list and one tool's page both exist. "My borrowed tools" does not — it was folded into the list as a label next to each borrowed tool, which answers the same need on a phone without a third screen.
- Data: the loans carry a member name, a tool and a date, and no phone number is collected. Nothing in the result says when a loan stops being kept, so that line of the plan is still undecided rather than wrong.
- Permissions: a visitor sees the list. The plan said a visitor sees nothing, and no step in the key flow needs a visitor to see anything, so this is a filled box with nothing requiring it.
- Key flow: a member picks a free tool, borrows it, and sees it marked as theirs. Two members picking the same tool a moment apart both get it — the failure path in the plan never says what should happen, so nothing in the result contradicts it.
Two lines matched, one had grown a permission nobody asked for, and one was never decided at all. Only the last two are work; the matching lines are simply done, and nothing needs saying about them.
Six ways a one-page plan fails, and the repair for each
These are not mistakes in building. They are mistakes in the page you wrote before building started, which is exactly why they are cheap to repair: the fix is a sentence, and it can be written without anyone opening the project.
| Failure | Why it costs you later | The repair |
|---|---|---|
| A page that no step visits | It has to be filled with guesses, and each guess is a decision nobody made. | Delete it, or add the step that needs it. There is no third option. |
| A permission with no step behind it | It becomes a promise about other people's data that nothing in the product keeps. | Clear the box and hand the same answer back to the flow: either a step needs it, or nobody does. |
| A data item kept "for later" | Every kept item is a promise to keep it safely, show it to the right person and delete it on request. | Ask which step reads it today. If none does, remove it and write down what it would cost to add it later. |
| A flow that only has the happy path | The first thing that goes wrong has no agreed answer, so it gets invented in the moment. | Add the mistake path and the failure path, each ending in one message the person can act on. |
| A page list longer than the flow | The path gets spread thin, and no single step is finished well enough to test. | Cut to the pages the flow actually passes through, and move the rest to the later list. |
| No line saying what is out of scope | Absence of a decision is read as an invitation, and the scope grows on its own. | Name at least two things, and be willing to receive the version without them. |
Comparison
The checklist the first version has to pass
This is the same list you would run on your own plan, written as things you do rather than things you believe. Keep it beside the plan: a first version that passes all six is ready to be shown to the people it was made for, and a first version that passes five is not, however good the five look.
Six checks, each with a result you can hold up
- Every page on the list appears somewhere in the key flow: walk the flow and tick the pages off as you meet them.
- Someone who has not read the plan can follow the key flow without asking you a question.
- The mistake path ends in a message that says what to do next, not only that something was wrong.
- The failure path ends the same way, and nothing was saved when it failed.
- Nobody can see or change anything the permissions line did not give them: try it in a private window and as a second person.
- Every item on the out-of-scope list is genuinely absent, and you can say so while looking at the result rather than at the plan.
Your next step
Three things to do with your own idea, in order. None of them needs an account, a tool or a Skill.
- Write your key flow as five numbered steps or fewer, with what the person sees after each one.
- Fill in the pages, data and permissions from that flow — nothing that the flow does not touch.
- Ask someone who has not heard the idea to read the one-page plan and tell you what they think it does.