What to Send a Developer Before an App Project: A 12-Point Brief

What to Send a Developer Before an App Project: A 12-Point Brief

> Quick Summary: A developer can only give you a reliable timeline and price if they know twelve things: the problem, the user, the three core actions, platforms, accounts and login, payments, content and data, integrations, design status, deadline, budget range and who decides. One page is enough. This is the list I ask every client for.

Most first messages I receive say "I want an app like X, how much?". Nobody can answer that honestly. The twelve points below turn the same idea into something that can be estimated in a day.

The 12 points

1. The problem in one sentence. What is hard or slow today, and for whom?
2. The user. Who opens the app, and in what situation? "Gym owners at the front desk" is useful. "Everyone" is not.
3. The three core actions. The three things a user must be able to do in the first version. Everything else is a later version.
4. Platforms. iPhone, Android, web, or a combination. If you are unsure, say where your users are.
5. Accounts and login. Do users sign up? With email, phone number, Apple, Google? Are there different roles, such as customer and admin?
6. Payments. Is anything sold? One-time purchase, subscription, or payment for a physical service? This changes store commission and the amount of work considerably.
7. Content and data. Who creates the content: you, the users, or an outside source? Does existing data need to be imported?
8. Integrations. Maps, notifications, calendar, accounting, a payment provider, an AI model, hardware. List what you already use.
9. Design status. No design, rough sketches, or finished screens? Share whatever exists, even a photo of a notebook page.
10. Deadline and why. A date with a reason (a trade fair, a season, a funding round) is planned differently from "as soon as possible".
11. Budget range. A range, not a number. It decides whether to build the full idea or a smaller first version, and saves both sides a week of emails.
12. Who decides. One person who can say yes. Projects slow down more from waiting for approvals than from code.

What you should get back

Within a few days of a brief like this, a serious developer should send:

• Questions about the points that were unclear. No questions at all is a warning sign.
• A scope list: what is in the first version and what is explicitly out.
• A timeline by phase. Mine is usually discovery (1 to 2 days), design and prototype (2 to 4 days), development and testing (5 to 10 days, depending on the project) and release (1 to 3 days).
• A price tied to that scope, and what happens when the scope changes.
• Who owns what: the code, the designs, the store accounts. The answer should be you.

Three things that are not needed

• A technical specification. Choosing the technology is the developer's job.
• A finished design. Sketches are enough to start.
• A signed NDA before the first message. Describe the problem and the user; keep the secret part for later if you must.

Frequently Asked Questions (FAQ)

Have the twelve answers? Send them through the contact page and I will reply within 24 hours.