How to brief an app developer

A fixed price is only as accurate as the brief behind it. Send a developer "an app like Uber, but for dog walkers" and you'll get back a guess, padded for everything you didn't say. Send one page that answers the right questions and you'll get a number you can plan around.

Here's the page I wish every project started with, the questions worth asking whoever you hire, and the signs that a quote won't hold.

The one-page brief

You don't need a spec. You need eight short answers:

• Who it's for. One kind of person, not "everyone". It decides what the first screen says.
• The one job. The thing the app does better than the alternative. If you can't say it in a sentence, the scope isn't ready.
• The core flow. The four or five steps someone takes to get that job done, from opening the app to finishing.
• Must have, and later. Two lists. More on this below.
• Platforms. iPhone, Android, web, or some of them. If you're unsure which technology to pick, I wrote a short guide.
• What you already have. Designs, a logo, a backend, an existing app, an API from another team. Each one changes the work.
• A budget range. Not to anchor the price, but so the developer can say what fits inside it.
• A deadline, and why. "March, because of a trade show" is more useful than "ASAP".

Briefone page · example

For

Patients of one physio clinic, booking from their phone

The one job

Book, move or cancel a session in under a minute

Core flow

OpenPick a timeConfirmReminder

Platforms

iOS and Android

Already have

Figma sketches, a booking calendar

Budget

$5,000 to $8,000

Deadline

In the stores by March

Must have

• Sign in
• Book and move
• Push reminder

Later

• Payments in app
• Exercise videos
• Chat

Describe the first version, not the dream

Most budget overruns are a scope that was never written down, or one that quietly included everything. Write every idea down, then split the list: what the first version needs so real people can use it, and what waits until they have.

The first version usually needs less than it feels like. Sign in, the core flow, the notifications that bring people back, and a clean release to the stores. An admin panel, chat, referrals and a web version are often better built after you've watched people use the app, because by then you'll know which of them matters.

Every idea

Sign inCore flowRemindersStore releaseAdmin panelChatDark modeReferralsWeb app

Version 1 · quoted

Sign inCore flowRemindersStore release

Later · after real users

Admin panelChatDark modeReferralsWeb app

Put the "later" list in the brief anyway. It tells the developer where the product is going, so the first version is built to grow into it instead of being rebuilt.

Freelancer, agency or a hire

Which one fits depends on what you need over the next year:

• A freelancer fits a defined first version or a revamp: one person, a fixed scope, a fixed price, and nobody lost between handoffs.
• An agency fits when you need a team at once (design, engineering and QA together) and the budget to pay for it.
• A hire fits when the product needs mobile work every week for years. It costs the most and takes the longest to start, and it's the only option that stays.

I compared what each one costs in what a mobile app actually costs.

Questions to ask anyone you hire

Whoever you talk to, these answers tell you more than a portfolio page:

• Can I see apps you've shipped, in the store? Screenshots are easy. A live listing you can download shows the work got through review and into people's hands.
• Who owns the code and the designs? The answer should be you, from day one, in your own repository and your own developer accounts.
• How will I see progress? You want builds you can install on your own phone while the app is being made, not a demo at the end.
• What exactly does the price include? Screens, backend, store release, the rounds of changes, and what happens when something is unclear.
• What happens after launch? Bugs will turn up in the first weeks. Ask who fixes them, for how long, and what ongoing work costs.

Red flags

• A price before any questions. If someone quotes a full app from one sentence, the number is either padded or wrong.
• No shipped work you can download. Nothing in the stores, nothing live on the web.
• "We'll figure out the scope as we go" on a fixed price. That's an hourly rate with extra steps.
• You only see the app at the end. By then, every misunderstanding is expensive.
• Code or accounts that stay in their name. You should be able to walk away with everything.

How it runs with me

The brief on my hire page is the one-page brief above, as a form. It takes about two minutes. From there:

1. 1Brief2 minWhat you're building, in your words
2. 2Call30 minQuestions, answered both ways
3. 3Planfixed scopeScreens, scope and one price
4. 4Buildon your phoneA new build to install as it grows
5. 5Shipand iterateStore release, then small updates

Every project is a fixed price, half up front, agreed after the call. You install and test every build on your own phone while it's being made. The code and designs are yours, and the app ships under your own developer accounts.

---

If you have an idea, a half-built app or a list of screens, fill in the two-minute brief. You'll get a reply within 24 hours, and after a 30-minute call, a scope and one price.