TL;DR
Explaining an app idea to a developer is not pitching. It is briefing. The developer does not need to be excited; they need to know exactly who the app is for, what one thing it must do for them, what the first five things a user does look like, and what you have decided not to build. Give them that on one page and the first conversation ends with a rough scope and a rough number. Give them a vision and a feature list and it ends with “send me more details”.
The one-page brief has eight parts: the problem in one sentence, the person who has it, the core job the app does, five user stories, a few sketches, what is out of scope, your constraints, and how you will know it worked. It is not a requirements document; it is what makes a good requirements document possible. And it is, almost line for line, the definition of your MVP, which is why the developers who build MVPs for a living will recognise it immediately.
Why “explaining the idea” goes wrong
Most first conversations between a founder and a developer fail in one of three ways, and all three come from the founder trying to do the wrong job. And if the goal is to sell the idea rather than build it, how to sell an app idea explains why the developer conversation is still the first step.
The vision pitch. The founder describes the company in three years: the platform, the marketplace, the AI layer, the network effects. The developer hears forty features and no first one. The quote, if it comes, is for the platform, and it is either enormous or a guess.
The feature list. The founder has written everything the app will do. The developer cannot tell which of the thirty items matter, so they either price all thirty or ask the founder to rank them, which the founder cannot do because they have never watched a user try to use it.
The secret. The founder will not describe the idea until an NDA is signed, so the developer is asked to estimate something they have not been told. The honest answer on NDAs is that a developer who wanted to steal your idea would need to want it more than the fifty ideas they hear a year, and that the protection that matters is owning the code. Sign an NDA if it makes you comfortable, then actually explain the idea.
The fix for all three is the same document: a brief that describes the first version for the first user, in enough detail to scope and in little enough detail that the developer can still tell you what is wrong with it.
The one-page brief
Eight parts. Each one is a few sentences, not a section. The whole thing fits on a page, and the discipline of fitting it on a page is most of the value.
1. The problem, in one sentence
Who has what problem, today, and what they do about it now. “Independent physiotherapists lose two to three hours a week chasing patients to confirm appointments by text, and about 15 percent of slots go unfilled because of late cancellations.” Not “the healthcare scheduling market is broken”. A developer can build for a physiotherapist losing hours; nobody can build for a broken market.
If you cannot write this sentence, the idea is not ready to explain yet, and validating it comes before briefing anyone.
2. The person
One user. Their job, their day, the device in their hand when the problem happens, how technical they are. “A physio running a solo practice, 35 to 55, on a phone between patients, uses WhatsApp and a paper diary, will not install anything that takes more than a minute to understand.” Every design decision the developer makes for the next two months comes from this paragraph. If there are two kinds of user (a marketplace has two), describe both and say which one the first version is for.
3. The core job
The one thing the app does that makes the person’s problem go away. One sentence, and it should be a verb. “Lets the physio send a confirmation request in one tap and see who has confirmed.” Not “a scheduling platform with reminders, analytics and a patient portal”. The single-feature MVP idea lives here: if the app did only this, would the person use it?
4. Five user stories
Five things a user does, in order, written as “As a [person], I [do something] so that [outcome].” The first is usually signing up or arriving; the last is the moment the core job is done.
- As a physio, I add a patient’s name and phone number so I can message them.
- As a physio, I tap “confirm tomorrow’s appointments” so every patient gets a message without me typing.
- As a patient, I tap “yes” or “no” in the message so I do not have to call.
- As a physio, I see who has confirmed, who has not, and who has cancelled, in one list.
- As a physio, I get a nudge two hours before an unconfirmed slot so I can fill it.
Five is the number because a first version with more than five stories is usually not a first version. If you have twenty, the other fifteen go in part six.
5. Sketches
Three to five screens, drawn by hand, photographed. Ugly is fine; ugly is better, because a polished mock-up makes a developer think decisions have been made that have not. What matters is that the developer can see the flow: this screen leads to that one, this button does this. If you have a reference app (“the list should feel like the Todoist list”), name it; that is worth a page of description.
6. What is out
The features you have decided not to build in the first version, listed, so the developer knows they are decisions rather than oversights. “Not in v1: online payments, a patient portal, calendar sync, analytics, multiple practitioners.” This list does two things. It tells the developer where the edges are, which is what makes a quote possible. And it tells them you have thought about scope, which changes how they treat you.
7. Constraints
Budget range, deadline if there is a real one (a pilot, a demo, a funding round), platforms (phone only? web only?), anything that must integrate with something existing, anything regulated (health data, payments, children). Founders hide the budget because they think it invites a quote at the top of the range. It does the opposite: a developer who knows the budget scopes to it, and one who does not scopes to the vision.
8. How you will know it worked
One number and a date. “Ten physios using it weekly by the end of month two, with confirmation rates above 80 percent.” This is the sentence that turns a build into an experiment, and it is the sentence a developer who builds MVPs will ask for if you do not offer it.
What to leave out
The brief is as much about what you do not say as what you do.
- The market size and the exit. The developer is not investing. Save it for investors.
- The technology. Unless you have a real constraint (must run on an existing system, must be a native iOS app for a reason), do not specify the stack. Telling a developer “it should be in React Native with a Node backend” when you do not know why makes them either follow a bad instruction or spend the meeting arguing with it. Describe the person and the device; let them propose the stack, and ask why.
- The competitors, at length. One line (“like Calendly, but for physios and by text”) is useful. A competitive analysis is not.
- Version two. Anything not in the five stories goes in “what is out”, as a list, without discussion.
- The forty-page document. If you have one, keep it. Send the page. A developer who wants the document will ask, and by then they will know what to look for in it.
The questions a good developer will ask back
You can tell a lot about a developer or an agency by what they ask after reading the brief. These are the questions that mean they build first versions for a living; if you get none of them, be careful.
| They ask | Because |
|---|---|
| “Which of the five stories is the one the whole thing depends on?” | They are looking for the core job, to build it first and prove it before the rest |
| “What happens today, without the app?” | The manual version is the cheapest validation there is, and it tells them what the app must beat |
| “Have you shown the sketches to any of the people in part two?” | If not, they will suggest you do, before they build, because it is cheaper than finding out after |
| “What is the number in part eight, and what would make you stop?” | They want the build to be an experiment with a result, not a project with a deadline |
| “Which of the ‘out’ list will you need in month three?” | So the first version’s architecture does not block it; this is scoping, and it is what separates an MVP from a demo |
| “What is the budget range?” | So they can scope to it rather than guess; a developer who does not ask will guess high |
| “Who owns the code, and where will it live?” | A good one raises the contract question before you do |
The questions you should be suspicious of: “Do you have a full specification?” before any discussion of the person or the job (they want to price a document, not solve a problem), and “We can build all of it” with no pushback on the “out” list (nobody who has shipped a first version says that).
From the brief to the MVP
Here is the part that makes this worth doing properly. The eight parts of the brief map almost exactly onto how an MVP is defined and built, which is why a developer who builds MVPs will recognise the page immediately.
Concretely: the problem and the person become the validation question the first version answers. The core job becomes the feature the developer builds first and puts in front of real users before anything else. The five stories become the first sprint. The sketches become the first wireframes. The “out” list becomes the scope boundary, and the feature prioritisation for what comes after. The constraints become the quote and the timeline (what an MVP costs and how long it takes both start from exactly these inputs). And the success number is what the launch is judged against.
When the developer turns the page into a formal document, that document is the MVP requirements document, and you can draft it yourself with the free PRD template. But the document comes second. The conversation the brief produces is what makes the document accurate.
A worked example: the brief, before and after
The same idea, explained two ways.
Before. “It’s like Uber for physiotherapy. Patients book, get reminders, pay in-app, rate their physio, and physios get a dashboard with analytics and a marketing tool to fill empty slots. Later we add insurers and a marketplace so patients can find physios near them. We’re thinking React Native. Can you give me a ballpark?”
The developer’s honest answer to that is somewhere between $80,000 and $400,000, which is no answer, and the founder leaves thinking developers are expensive and evasive.
After. “Solo physios lose two to three hours a week confirming appointments by text and about 15 percent of slots go unfilled. One user: the physio, on a phone between patients, WhatsApp and a paper diary. The app does one thing: one tap sends every tomorrow-patient a confirmation request and shows who said yes. Five stories [as above]. Three sketches attached. Not in v1: payments, patient portal, calendar sync, analytics, multiple practitioners. Budget $25,000 to $40,000, no hard deadline, phone-first. Success: ten physios using it weekly by the end of month two, confirmations above 80 percent.”
The developer’s honest answer to that is a scope, a number in the range, a timeline of six to ten weeks, two or three questions from the table above, and probably one suggestion that makes the first version smaller. That is what the first conversation is supposed to produce.
Who you are explaining it to changes the page a little
- A freelancer needs the brief plus a clear statement of what “done” means, because there is nobody else to define it. Freelancer vs agency covers the trade-off.
- An agency or MVP studio will usually turn the brief into a scope and a fixed quote themselves, and will push back on the “out” list, which is the service you are paying for. If you are choosing between several, the brief is what you send with the RFP.
- A technical co-founder candidate gets the same page, and their reaction to part six tells you whether they think like a founder.
- A no-code or AI tool, if you are building it yourself, gets the five stories one at a time, which is the whole secret of getting good output from those tools. MVP for non-technical founders covers that path.
Mistakes founders make in the first conversation
- Leading with the vision. Lead with the person and the problem; the vision is one line at the end if it is anywhere.
- Hiding the budget. It produces a quote for the vision instead of the version.
- Refusing to describe the idea until an NDA is signed. Sign one if you like; then describe it. An estimate of an unexplained idea is a guess.
- Specifying the stack. Describe the constraint, ask for the recommendation, ask why.
- Having no “out” list. Every feature you did not exclude is in the quote.
- No success number. Without it the build is a project; with it, it is an experiment, and experiments are cheaper.
- Sending the forty pages. Send the one; keep the forty for when they ask.
Conclusion
A developer does not need your vision. They need one page: the problem, the person, the core job, five stories, a few sketches, what is out, your constraints, and one number that means it worked. That page is what turns the first conversation into a scope and a quote, it is what a good developer will ask you for anyway, and it is, without using the word, the definition of your MVP.
If you have the page and want it turned into a scope, a fixed quote and a first version in a few weeks, that is the conversation we start with as an MVP development company, and it usually begins with us making the page shorter. Start it here.
Related guides
- How to turn your idea into an app
- MVP requirements document
- MVP scope
- MVP RFP template
- How to protect your app idea
- MVP for non-technical founders
- Free MVP PRD template
- MVP consulting
Frequently Asked Questions
How do I explain my app idea to a developer?
On one page: the problem in one sentence, the one person who has it, the one job the app does for them, five user stories in order, three to five hand-drawn screens, the features deliberately left out of the first version, your constraints (budget range, deadline, platform, regulation), and one number that means it worked. That is enough for a developer to scope and quote, and it is the shape of an MVP.
What should I include when describing an app idea?
Who has the problem and what they do about it today; the core job the app does, as a verb; the first five things a user does; sketches or a reference app; what is out of scope; budget, deadline and platform; and a success metric. Leave out the market size, the exit, the technology stack and version two.
Do I need an NDA before explaining my app idea to a developer?
Not usually. Ideas are not what gets stolen; execution is, and the protection that matters is owning the code you pay for. An NDA is reasonable if it makes you comfortable and most developers will sign one, but refusing to describe the idea until it is signed just means the estimate is a guess. How to protect your app idea on this site covers what actually protects you.
Should I tell the developer what technology to use?
Only if you have a real constraint, such as an existing system it must integrate with or a regulated environment. Otherwise describe the person and the device and ask the developer to recommend a stack and explain why. Specifying a stack you do not understand either sends them down a bad path or spends the meeting arguing about it.
Should I tell a developer my budget?
Yes, as a range. A developer who knows the budget scopes to it; one who does not scopes to the vision and quotes accordingly. Hiding the budget produces higher quotes, not lower ones.
How detailed should my app idea description be?
One page. Detailed enough to scope from (a real person, a real job, five stories, a clear out-list, constraints) and short enough that the developer can still tell you what is wrong with it. The formal requirements document comes after the first conversation, not before.
What is the difference between an app idea brief and a requirements document?
The brief is one page written by the founder before the conversation: problem, person, job, stories, sketches, exclusions, constraints, success. The requirements document is the detailed specification written after it, usually with the developer, covering every screen, rule and acceptance criterion. The brief makes the document accurate; the document makes the build precise.
How do I know a developer understood my app idea?
By the questions they ask back: which story the whole thing depends on, what happens today without the app, whether you have shown the sketches to real users, what the success number is, and which of the excluded features you will need in month three. A developer who asks none of those and says they can build all of it has not understood it, or does not build first versions.
How does explaining my app idea relate to building an MVP?
The one-page brief is the MVP scope in plain language. The core job is the single feature the first version proves, the five stories are the first sprint, the out-list is the scope boundary, the constraints become the quote and timeline, and the success number is what the launch is judged against. A founder who writes the brief has scoped their MVP without using the word.
Can I explain an app idea to an AI app builder the same way?
Yes, with one change: give it the five stories one at a time rather than the whole page at once. The person, the core job and the out-list still matter, because they stop the tool building the vision instead of the version. MVP for non-technical founders covers building it yourself.
