I have an app idea — now what? Write the one-page press release before your first prompt

From the authors' site, workingbackwards.com: "Most of Amazon's major products and initiatives since 2004 have one thing in common—they were created through a process called Working Backwards." The document at its centre is the PR/FAQ: a press release followed by a list of questions and answers.

The press release has a fixed order. A heading that names the product so the target customer understands it in one sentence. A subheading that names the customer and the benefit. A summary paragraph with the launch framing. A problem paragraph written from the customer's perspective. A solution paragraph that says how the product removes the problem. Then quotes and getting started: "Add one quote from you or your company's spokesperson and a second from a hypothetical customer describing the benefit of using your new product," and a line on how the customer begins.

The FAQ has two halves. External questions are the customer's — price, how it works, support. Internal questions are the company's — technical risk, cost, what has to be true. The language rule for both: "no corporate jargon."

Two things about the Amazon version that you do not need: the review meetings, where a room of executives reads the document in silence and then interrogates it; and the internal FAQ's breadth, which covers legal, finance, and operations. For one person, the review is you reading the page the next morning. Keep the forcing function; drop the ceremony.

The one-page limit is our adaptation, not Amazon's rule; it exists because a solo builder who writes six pages before prompting will not write them, and because the discipline is in the cutting. Every block below is a question you must answer in plain words. If a block is hard, that is the block that was going to be hard in the app.

1. Headline. The app's name and what it does, in one sentence a stranger understands. No adjectives.

2. Subheading. Who it is for — a person, not a segment — and the one thing they get.

3. The launch line. "Today, [name] is available on the App Store for [person]." Writing "today" is the point: it makes you describe a finished thing.

4. The problem. Three to five sentences from the person's point of view. What they do now, where it breaks, what it costs them (time, money, embarrassment). No mention of your app yet.

5. How it works. Three to five sentences on what the person does with the app, in order, from opening it to the moment the problem is gone. This paragraph is the first feature list you will ever write, and it is written as behaviour, not as screens.

6. Your quote. One sentence from you on why you built it. If the sentence could be said by anyone about any app, rewrite it.

7. The customer's quote. One sentence from a hypothetical user describing the benefit — Amazon's word, hypothetical. Write it in their vocabulary. If you cannot hear a real person saying it, the benefit is not real yet.

8. Getting started. One or two sentences: where they get it, what it costs, what happens in the first minute.

Then five FAQ lines, and no more:

• What is it not? Two or three things a reader might assume that you will not build.
• What does it cost? Free, paid, subscription; pick one now, change it later.
• Which platform first? iPhone, Android or both. Write the reason in six words.
• What is version 1? The smallest set of "how it works" sentences that still removes the problem.
• What would make me stop? The one fact that, if true, means you should not build this. Then go find out whether it is true.

The app below does not exist; the quotes are hypothetical by the method's definition. It is here so you can see the size of each block.

Read the FAQ's last line again. That is the experiment you run before the first prompt, with five friends and a paper list, and it costs nothing.

Run these on your own page. Each takes a minute.

The stranger test. Show the headline and subheading to someone who does not know you. Ask them to say back who the app is for and what it does. If they add a word you did not write, the headline is missing that word.

The delete-the-adjective test. Remove every adjective from the page. If a sentence stops meaning anything, it was carrying no fact. "A beautiful, simple way to track your fridge" becomes "a way to track your fridge"; the fact that survives is the product.

The competitor test. Put a competitor's name in place of yours in the headline and subheading. If the sentences are still true, you have described the category, not the app. Rewrite until the swap breaks the sentence.

The name-a-person test. The subheading's customer must be someone you can name — a friend, a colleague, yourself. If the customer is "busy professionals", you have not met them yet. Go meet one and come back.

The press release is not the prompt. It is the source the prompt is cut from, and the source the plan is checked against.

In Modaal, the new-project wizard takes "your PRD or a description of the first feature." Paste the whole page. Plan mode then writes a spec with the sections Overview, User Scenarios, Technical Approach, Implementation Steps, Files to Modify, Risks & Open Questions, Testing Strategy — and you check each section against the page you wrote: the Overview should be your headline and subheading in other words; User Scenarios should be your "how it works" paragraph, one scenario per sentence; Risks & Open Questions should contain your "what would make me stop" line. If the plan invents a feature the page does not mention, delete it from the plan before you approve.

In any other tool, the mapping is the same by hand. The first prompt is your "how it works" paragraph, one sentence at a time: "Feature 1: when the user photographs a receipt, produce a list of items with dates." The problem paragraph goes into the project's instructions file (AGENTS.md, CLAUDE.md, or the tool's equivalent) so every later prompt is answered in that context. The "what is it not" line goes there too, as a rule.

What the page prevents, concretely: the agent adding login before there is anything to log into; a settings screen with nine toggles for a version 1 with one behaviour; a second platform before the first has a user; and the twentieth prompt that says "make it better" because you no longer remember what better meant. The requirements template is the next document — the engineering-facing one — and it is much easier to fill in once this page exists. Spec-driven mobile app development covers the loop after that: one feature, one spec, one plan, one approval.

The customer is "everyone". The subheading cannot be written; that is the signal. Pick the one person you know best who has the problem and write for them. A second person can be added in version 2.

The problem paragraph mentions the app. "People need an app that…" is a solution paragraph, not a problem paragraph. Rewrite it as what the person does today with no app at all.

The customer quote is your quote. "This app changed how I cook" is marketing. "I stopped buying the second bag of spinach" is a person. If the quote contains the word "app", it is probably yours.

"How it works" is a list of screens. Screens are how the agent will implement behaviour; the page describes the behaviour. "A home screen with three cards" says nothing; "every morning it shows the three items closest to their date" says what and why.

The FAQ's last line is missing. Write the line that could stop the project, then test it before the first prompt: a paper prototype and five friends take an evening; building the app first takes a month. iOS or Android first covers the platform line; how to build a mobile app from scratch covers everything after this page, and the vibe coding guide covers working with the agent once the plan is approved.