How to write a brief developers can quote.

Send "I want a food delivery app for my city" to five developers and you'll get five very different numbers. That isn't because they're dishonest. They're each guessing at a different product.

A one-page brief fixes most of this. It doesn't need to be technical. It needs to be clear.

• The problem, in one or two sentences, and who has it.
• Who will use the product. If there's more than one type of user (customers and shop owners, say), list each.
• The main things each user needs to do, written as simple steps. "Customer picks a time slot and gets a confirmation on WhatsApp."
• Where it runs: web, Android, iOS, or a mix.
• What it needs to connect to: payments, SMS, an existing system, a spreadsheet you use today.
• What's out of scope for now. This is as useful as what's in.
• Your rough timeline and budget range, if you have them.

Founders often hide the budget, worried that the quote will rise to match it. In practice, a range helps a good developer suggest what fits. Without it, they guess, and you get a quote for a product you can't afford or one so stripped down it won't work.

Colours, fonts and logo ideas can come later. So can the choice of technology, unless you have a real reason for a specific one. Long lists of features from other apps aren't useful either. Describe what your user needs to get done, and let the team suggest how.

A rough drawing of the main screens on paper, photographed on your phone, removes a lot of guessing. It doesn't need to look good. Boxes and arrows are enough.

When quotes arrive, check that each one covers the same things. Does it include design? Testing? Publishing to the app stores? Fixes after launch? A cheap quote that leaves out half the work isn't cheap.

The team that asks you the most questions about your brief is often the one worth talking to.