How to Write a Mobile App Brief Before You Hire a Developer in Lebanon

Most app projects that go wrong in Lebanon do not go wrong in the code. They go wrong in the first conversation, when the client says "an app like Talabat but for our shop" and the developer nods, and each of them pictures something completely different. Three months later the developer delivers what they pictured, the client is disappointed, and the argument is about money.

A brief is how you prevent that. Not a fifty-page specification — nobody reads those, and you do not need one for a first version — but two or three pages that answer the questions a developer will otherwise answer for you, silently, in the way that is easiest for them.

This guide walks through what to put in it, in the order a developer needs it, including the parts that are specific to building an app for Lebanese users.

Start with the one job the app does

Write one sentence: who opens this app, and what do they get done in it. "Our regular customers reorder their usual water and gas delivery in under a minute." "Our field technicians log each visit with photos, and the office sees it the same day." "Parents see their child's bus location and get a message when it arrives."

If you cannot write that sentence, you are not ready to hire a developer yet — you are ready to hire someone to help you think, or to test the idea more cheaply first. Many first versions do not need to be native apps at all; a well-built mobile website or a no-code tool can prove demand for a fraction of the price, and our guide to no-code app and website costs covers when that is the smarter move.

Then add one line on why an app, specifically. Push notifications, the camera, location, offline use, a home-screen icon for something people use every week — those are real reasons. "Everyone has an app" is not, and a developer who hears it will reasonably wonder what else you have not thought through.

Who uses it, and in which roles

List every kind of person who touches the system. Customers, obviously. But also your staff who receive the orders, a driver who marks deliveries, a manager who changes prices, and you, checking what happened today.

This is where budgets quietly double. Every role is its own set of screens and permissions, and the one people forget is the admin side: the place where someone adds products, answers a complaint, refunds an order or blocks an abusive account. An app with no admin panel is an app where every change means calling the developer. Say in the brief whether you expect a web dashboard for staff, what they need to do in it, and who they are.

List the journeys, then the screens

Features lists produce bad quotes, because "user accounts" can mean anything from a phone number and a code to a full profile with addresses, payment methods and order history.

Instead, write the journeys, step by step, in plain language:

1. A new customer downloads the app, enters their phone number, receives a code, and lands on the product list.
2. They choose two items, pick a delivery time, confirm their address, and choose to pay cash on delivery.
3. The shop gets a notification, accepts the order, and the customer sees "accepted".
4. The driver marks it delivered; the customer is asked to rate it.

From journeys like these, a good developer or app UI/UX designer can derive the screens, and you can both see what is missing. Add rough sketches if you have them — photos of pen-on-paper boxes are genuinely useful — and name two or three existing apps whose way of doing one specific thing you like, saying exactly which thing.

Arabic, English, or both: decide now

If any of your users will use the app in Arabic, write that in the first page of the brief, not as an afterthought.

An Arabic interface is not English text replaced with Arabic text. The whole layout mirrors: navigation, icons with direction, progress bars, the order of fields, swipe gestures. Arabic text needs fonts that render it properly at small sizes, and mixed lines — an Arabic sentence with an English brand name and a phone number inside it — need care to display in the right order. An app designed in English and "translated later" usually needs its screens redone, which is the expensive way to do it.

So say which languages you need at launch, which is the default, and whether users switch inside the app or it follows the phone's setting. If French matters to your audience, say that too. And decide who writes the in-app text in each language; it is a small amount of copy, but it is what users actually read.

How money moves, if it does

Payment is the part of an app brief where Lebanese reality matters most, and where assumptions cost the most.

Write down exactly how customers will pay you today and how you would like them to pay in the app: cash on delivery, card payment through a payment provider, a transfer through a wallet service your customers already use, or no payment in the app at all. Then let the developer confirm, for your specific business and bank, what is actually available and what integrating it involves — availability depends on your business setup and your provider, not on what an app in another country does.

Two further points belong here. If you plan to sell digital content or subscriptions consumed inside the app, the app stores have their own rules about in-app purchases, and your developer should explain how they apply before anything is designed. And if you only need cash on delivery at launch, say so plainly — it may remove a whole milestone from the first version.

Weak connections and older phones

Your users are not all on fast fibre and new phones. Mobile data drops, power cuts take Wi-Fi down with them, and plenty of people carry mid-range or older Android handsets.

Put this in the brief as requirements, not hopes. What must still work when the connection drops mid-action — does an order get lost, or does it wait and send? Which screens should load from what the phone already stored? Should images be compressed on upload so a technician in a village can still send them? Which is the oldest phone you want to support? These decisions change how the app is built, and they are far cheaper to make before the build than after the first bad reviews.

Accounts and ownership: in your name, from day one

This is the paragraph that protects everything else. Write it into the brief as a condition:

• The Apple Developer Program account and the Google Play Console account are opened in your business's name, by you, and paid by you. At the time of writing, Apple charges $99 a year and Google a one-time $25 registration fee. Organisation accounts with Apple ask for a D-U-N-S number for your business, which can take time to obtain, so start early.
• The server, database and any cloud accounts are opened in your name, with the developer added as a user.
• The source code lives in a repository you own, and the developer pushes to it throughout the project, not just at the end.
• Any paid services the app depends on — maps, messaging, email, analytics — are in your name too.

Developers who have worked with serious clients expect this and will not argue. Our notes on who owns delivered work and how to hire a mobile app developer go further on why an app held in someone else's account is an app you do not really have.

What is in version one, and what waits

Sort every feature into three columns: must have at launch, should have soon after, and later. Be ruthless with the first column. Loyalty points, referral codes, chat, multiple branches and a dark mode are all reasonable ideas; very few of them are what decides whether the first version succeeds.

This one exercise does more for your budget than any negotiation. It also gives the developer permission to tell you honestly what each item costs, because it is clear you are choosing, not demanding everything.

Budget, timeline and milestones

Give a budget range. Clients hesitate because they fear anchoring the price upward, but a brief without a budget gets quotes for three different apps. On Furrsati, a simple cross-platform MVP with a limited feature set and backend is typically priced $2,500 to $7,500 per project, and a full app interface of roughly 10 to 20 or more screens, designed by a UI/UX specialist, is typically $1,500 to $4,000. Our breakdown of app development costs in Lebanon explains what moves a project from one end of that range to the other.

Give a date you actually need, and why — a season, an event, a funding conversation — so the developer can tell you what fits.

Then ask for milestones that each end in something you can see and test on your own phone: designs approved, then the core journey working in a test build, then payments and the admin side, then store submission. Designing first and building second is almost always cheaper than discovering in week eight that the screens need rethinking. If you want a short animated clip for the store listing or a launch post, that is a separate small job for a motion graphics designer, typically $80 to $300 for 15 to 30 seconds, and it does not need to wait for the developer.

Our guide to setting milestones covers how to size them.

A one-page template

If you want a starting point, answer these under headings and you have a brief most developers can quote from:

1. The one job: who uses it, to do what, and why it must be an app.
2. Roles: every type of user, including staff and admin.
3. Journeys: three to six step-by-step journeys in plain language.
4. Languages: which, which is default, who writes the text.
5. Payments: how money moves at launch, and later.
6. Conditions: connection, devices, what must work offline.
7. Ownership: store, server, code and service accounts in your name.
8. Version one: must, should, later.
9. References: apps you like, and exactly what you like about each.
10. Budget, date and milestones.

It is the same discipline as a website brief, with more attention to roles, devices and accounts.

Hiring and paying safely

Send the same brief to several candidates and compare how they respond, not only what they charge. The good ones ask questions about your journeys, flag something you missed, and suggest cutting a feature. The risky ones reply with a price in ten minutes. Ask each to show an app they built that is live in the stores, and to tell you what they would build first.

This is where Furrsati removes the risk. You post your project, compare proposals from verified freelancers, fund a milestone, and release payment only once you've approved the work, with milestone funds held by Stripe until you release them. The service fee comes off the freelancer's side, so only standard card processing is added to your bill, and wallet-funded milestones carry none. Freelancers verify their identity before they can withdraw; as a client you need no verification. Payouts reach the freelancer inside Lebanon by OMT, Whish, bank transfer or USDT.

Your next step

Write the one-sentence job and the three most important journeys today, before you talk to anyone. Open the Apple and Google developer accounts in your business name this week, because the verification can be slow. Then turn the rest of the template into two pages, and when you're ready, hire a mobile app developer on Furrsati — or start with an app UI/UX designer if you want the screens settled before the build is quoted.

Frequently Asked Questions

What should a mobile app brief include?

The one job the app does and for whom, every type of user including staff and admin, three to six step-by-step user journeys, the languages at launch, how payment works, requirements for weak connections and older phones, a condition that all store, server and code accounts are in your name, a must/should/later feature list, reference apps, and your budget, date and milestones.

How long should an app brief be?

Two or three pages is enough for a first version. Its job is to answer the questions a developer would otherwise answer for you. A long specification written before you have spoken to anyone tends to fix the wrong details; a short, clear brief gets better questions and more comparable quotes.

Should I include a budget in my app brief?

Yes. Without a range, developers quote for very different apps and you cannot compare them. On Furrsati a simple cross-platform MVP is typically $2,500 to $7,500, and a full app UI of 10 to 20 or more screens is typically $1,500 to $4,000. Giving a range lets developers tell you honestly what fits inside it.

Who should own the App Store and Google Play accounts?

Your business, from day one. Open the Apple Developer Program account (at the time of writing $99 a year) and the Google Play Console account (a one-time $25 fee) in your business name and add the developer as a user. Keep the server, code repository and paid services in your name too.

Do I need to plan for Arabic from the start?

If any users will use the app in Arabic, yes. An Arabic interface mirrors the whole layout right to left and needs proper fonts and handling of mixed Arabic, English and numbers. An app designed only in English and translated later usually needs its screens reworked, which costs more than designing both from the start.

Should I hire a designer or a developer first?

For most apps, a UI/UX designer first. Settled screens and journeys give developers something precise to quote, and changes are far cheaper in design files than in code. Some developers offer both; if so, make approved designs the first milestone before any building starts.