How to Create an App Project Brief That Gets You Comparable Quotes

App briefs fail differently from website briefs. A website is mostly pages; an app is mostly behaviour. The cost sits in invisible places: the admin dashboard nobody mentioned, the backend that serves the app, the payment reconciliation, the notification logic, the second platform, and the app-store submission process.

If your brief describes only what the customer sees, every quotation you receive will be based on a different set of assumptions about everything else. This guide sets out how to write a brief that removes those assumptions.

Brief, specification or contract: which one are you writing?

These three documents get confused, and the confusion costs money.

You are writing the first one. That means describing intent and boundaries, not screen-by-screen behaviour. If you already know every screen and rule, you are writing a specification, and you should expect to pay for discovery anyway because the vendor must validate it.

A brief is judged by one test: could three firms read it and produce proposals you can lay side by side?

The nine questions a development firm needs answered

Rather than a rigid template, work through these nine questions. Answer each in a few sentences and you have a brief.

1. What is the business and what problem does the app solve? Two paragraphs, plain language, no vision statements.
2. Who uses it? Every role, including your own staff.
3. What must each role be able to do? The core actions, in plain verbs.
4. Which platforms and devices? Android, iOS, both, plus any tablet or web requirement.
5. What must it connect to? Payments, delivery partners, accounting, SMS, WhatsApp, an existing database.
6. Who administers it after launch? Which staff, doing what, on what screens.
7. What does success look like in six months? One or two measures.
8. What is the budget band and the deadline? And what drives the deadline.
9. What are you explicitly not asking for? The out-of-scope list.

Question nine saves the most money and is omitted from most briefs.

Defining user roles before features

Feature lists written without roles produce ambiguous quotations. Define roles first, then attach actions to them.

Five roles is common; each one implies screens, permissions and testing. A brief listing only "customer" hides perhaps half the build. Nigerian operations frequently need a rider role and a branch role that nobody thinks to mention until the demo.

The feature ladder: must, should, could, later

Do not submit a flat feature list. Grade it, and vendors can quote a base build plus priced options, which is what you need when the first round of quotations exceeds your budget.

Must have. Without these the app has no purpose. For a retail app: account creation, catalogue, cart, payment, order status, admin order management.

Should have. Materially improves the product but the app can launch without it: saved addresses, order history, push notifications on status change, promotional codes.

Could have. Worth doing if budget allows: loyalty points, referral codes, in-app chat, multiple saved cards.

Later. Explicitly deferred to a second phase: subscriptions, multi-vendor support, a web version, analytics dashboards beyond basic reporting.

Write the "later" list down. It reassures vendors that you understand phasing, and it stops your own team from smuggling features into phase one.

A note on phone number, OTP and account creation

In Nigeria, phone-number registration with a one-time password is usually the right default, and it is not free: it requires an SMS provider, costs per message, and needs fallback handling when delivery fails. State whether you want it, because it is a common source of quotation differences.

The invisible half: backend, admin and integrations

Roughly half the cost of a business app sits behind the screens your customers see. Address it explicitly.

Backend. The app needs a server, a database and an API. Say whether you have an existing system it must use, or whether the vendor builds one. Ask for hosting cost estimates separately, since cloud hosting for an app typically runs ₦150,000–₦800,000+ per year, indicatively.

Admin dashboard. Someone in your business must manage content, users, orders, prices and refunds. An admin area is a small web application in its own right. Briefs that omit it produce quotations that omit it, and then you discover at handover that changing a price requires a developer.

Integrations, listed individually:

• Payments, naming the provider you intend to use, such as Paystack or Flutterwave.
• Bank transfer confirmation, if you accept transfers.
• SMS or WhatsApp notifications.
• Delivery partner APIs, if you use one.
• Accounting or inventory systems you already run.
• Maps and location services.
• Analytics and crash reporting.

Data and reporting. State the three to five reports your management actually needs. "Reporting" as a single word is unpriceable.

Platforms, devices and offline behaviour

Be specific here, because it changes cost substantially.

• Android only, iOS only, or both? Many Nigerian consumer apps launch Android-first and add iOS later. Say if that is your plan.
• Cross-platform or native? Unless you have a technical constraint, describe your priorities such as budget, speed to market or heavy device features, and let vendors propose an approach with reasons.
• Minimum device and OS support. Supporting older, lower-specification Android devices is realistic in Nigeria and affects testing effort.
• Offline behaviour. What should happen when the network drops mid-order? Options range from "show an error" to "queue and sync later". The second is considerably more expensive and sometimes essential, particularly for field staff and rider apps.
• Data usage. State that the app should be usable on limited data, and expect the vendor to explain image handling and caching.
• Web companion. Say whether customers must also be able to use the service in a browser. Assuming it is included is a common and costly misunderstanding.

Accounts, launch and who owns what

Launch logistics belong in the brief because they carry cost and delay.

• Developer accounts. The Apple Developer Program has historically been a yearly fee of US$99 and Google Play developer registration a one-time US$25 fee; verify current fees with Apple and Google. State whether the accounts will be registered in your company's name, which they should be.
• Store listing assets. Icon, screenshots, description, privacy policy URL. Say who produces them.
• Review process. Both stores review submissions, and rejections happen. Ask vendors to describe how they handle resubmission.
• Source code and ownership. State plainly that you expect ownership of the source code and all accounts on final payment, and ask for handover terms in the proposal.
• Support after launch. Say what you expect: a warranty period for defects, then a maintenance arrangement. App maintenance is typically 15–25% of the build cost per year, indicatively.

Budget band and timeline

State a band. Withholding your budget produces proposals scoped at random.

Indicative 2026 ranges for Nigerian app projects; actual quotes vary with scope, vendor and exchange rate:

Give the deadline with its reason: an investor milestone, a season, a contract start date. Vendors can then tell you whether the date is achievable at the scope you want, or which features must move to phase two.

Example (hypothetical): brief extract for a pharmacy delivery app

Example (hypothetical). A pharmacy group with four Lagos branches wants customers to order medication for delivery.

Problem: Orders arrive through four WhatsApp lines. Staff copy items into a book, call riders and reconcile at night. Errors on dosage and delivery address are frequent, and no one can tell which branch fulfils fastest.

Roles: Customer, branch pharmacist, rider, head-office administrator, finance.

Must have: Phone registration with OTP; product catalogue with prescription flag; prescription photograph upload; cart and checkout with card and bank transfer; branch assignment by location; rider assignment and proof of delivery; admin catalogue and order management.

Should have: Repeat order; order status notifications; refund handling in admin.

Could have: Saved prescriptions, reminders for chronic medication.

Later: Loyalty scheme, iOS version, insurance or HMO integration.

Platforms: Android first, iOS in phase two. Must work on mid-range devices over mobile data.

Integrations: Paystack for cards and transfers; SMS provider for OTP; existing inventory spreadsheet to be replaced, not integrated.

Out of scope: Telemedicine consultation, pharmacist chat, multi-vendor marketplace.

Regulatory note: The group will confirm its own obligations for handling prescriptions and health data with the relevant Nigerian authorities and its legal adviser; the vendor must support consent capture and restricted access to prescription images.

Budget band: ₦8,000,000–₦14,000,000 for phase one. Deadline: pilot in two branches within four months.

Every one of those lines removes an assumption a vendor would otherwise make silently.

What changes for Nigerian businesses

Payment behaviour. Card penetration is uneven and bank transfer is widely preferred. If you accept transfers, the app needs a confirmation mechanism and a reconciliation view for finance. Saying "accept payments" is not enough; name the methods.

Delivery reality. Lagos traffic, informal addressing and landmark-based navigation mean address capture should allow free-text landmarks and a phone number for the rider. A rigid address form designed for a different market will frustrate everyone.

Connectivity. Field roles such as riders and branch staff lose signal routinely. Decide deliberately whether their screens queue actions offline, and put that decision in the brief because it affects cost materially.

Device reality. Test expectations should include mid-range and older Android devices, not only flagship phones. Ask vendors which devices they test on.

Data costs. Large images and video-heavy onboarding burn customer data and drive uninstalls. State that the app must be light.

WhatsApp coexistence. Customers will still message you. Decide whether the app links to WhatsApp for support and whether notifications go by push, SMS or both, and note the recurring SMS cost.

Data protection. Any app collecting personal data brings obligations under the Nigeria Data Protection Act 2023, and app stores require a published privacy policy. Confirm requirements with the Nigeria Data Protection Commission or a qualified adviser, and put the policy in the brief as a deliverable with a named owner.

Company accounts. Register store accounts, payment gateway accounts and cloud accounts in the company's name using CAC documentation, not a developer's personal details.

How to issue the brief and compare responses

1. Shortlist three to five firms with published work in a comparable category.
2. Send the identical brief on the same day, with a response window of ten working days for anything above a simple MVP.
3. Require a fixed response structure: understanding, proposed scope by role, what is excluded, technical approach with reasons, team composition, milestone timeline, price split into design, build, backend, admin, integrations and QA, plus first-year running costs and maintenance terms.
4. Ask each firm one probing question: how would they handle a customer who loses network after payment is debited but before the order is confirmed? The answers reveal engineering maturity quickly.
5. Compare on one sheet, including exclusions and first-year total cost, not just the build price.
6. Interrogate the cheapest quotation. It usually omits the admin dashboard, QA, store submission or post-launch support. Ask which.
7. Check two live apps the firm built, on your own phone, and look at recent update history in the store.

Mistakes to avoid

• Describing only the customer app. The admin dashboard and backend are half the cost and all of the operability.
• A flat feature list with no priorities. You lose the ability to cut scope intelligently when quotations arrive.
• Silence on platforms. "An app" could mean one platform or three builds.
• Ignoring offline behaviour. For rider and field roles this is a major cost driver either way, so decide rather than leave it open.
• No out-of-scope list. Vendors will assume, and the assumptions will not match.
• Hiding the budget. It produces proposals aimed at the wrong scale.
• Forgetting store accounts and the privacy policy. Both delay launch and neither is the developer's decision to make for you.
• Treating maintenance as optional. Operating systems, devices and store rules change; an unmaintained app degrades within a year.

App brief checklist

• Business problem stated in plain language
• All user roles listed, including internal staff
• Core actions listed per role
• Features graded must, should, could and later
• Platforms, minimum devices and offline behaviour stated
• Backend expectation stated, including any existing system
• Admin dashboard requirements described
• Integrations listed individually with named providers
• Reports management needs listed
• Store accounts, ownership and privacy policy responsibilities assigned
• Budget band and deadline with reason
• Out-of-scope list written
• Success measures for six months after launch
• Response structure and deadline specified

Conclusion

An app brief is not paperwork; it is the mechanism that turns four unlike quotations into a decision you can defend. Define the roles before the features, grade every feature, describe the backend and admin work that customers never see, name the integrations, state the platforms and offline expectations, and write down what you are not asking for.

Then give every firm the same document, the same response format and the same deadline. The quality of the proposals you receive will improve immediately, and so will the quality of the conversations that follow.

If you would like your draft brief reviewed for gaps, or a realistic view of what your scope implies for cost, timeline and phasing, Linestech can go through it with you before you invite quotations.

Frequently asked questions

How detailed should an app brief be before I contact developers?

Detailed enough that a firm can price it without guessing: roles, core actions, platforms, integrations, admin needs, budget band and deadline. Screen-level detail is not required and can be counterproductive, because discovery with a good vendor usually improves the design. Three to eight pages suits most Nigerian SME projects.

Should I include wireframes or sketches?

Rough sketches of two or three key screens help communicate intent, particularly for unusual workflows. Polished designs are different: if you already hold a complete design, say so, because it changes the quotation. Do not pay for full design work before you have chosen a development partner unless you are certain the design is buildable.

What if I have an app idea but no clear feature list?

Start with the problem and the roles. Write what each user must be able to accomplish, not which buttons exist. If you genuinely cannot define that, commission a short paid discovery phase from one firm to produce a scoped brief, then use it to obtain competitive quotations for the build.

Do I need to specify the technology?

Usually not. State your constraints instead, such as an existing backend, an in-house team's skills, or a strong preference for one codebase across both platforms. Let vendors propose and justify their approach. A brief that dictates technology without reason narrows your options and may raise the price.

How do I protect my idea when sending a brief to several firms?

Send a non-confidential version of the brief for the first round, keeping proprietary business logic out of it, and use a mutual non-disclosure agreement before detailed discussions. In practice, execution matters far more than the concept, but reasonable caution costs nothing and a written agreement is straightforward to arrange.

Should the brief say how many users we expect?

Yes, at least in order of magnitude, plus any expected peaks such as a promotional period. Expected load affects backend architecture and hosting cost. Stating "a few hundred users in year one" versus "tens of thousands from launch" produces very different, and equally valid, technical proposals.

How long does it take to write a good app brief?

Between a day and a week for most businesses, depending on how many internal roles are involved. The slowest part is agreeing internally what is must-have. That argument is far cheaper to have before quotations than during development, when every change carries a price.

Can the brief be reused for a second phase?

Yes, and it should be. Keep the "later" list as the starting point for phase two, updated with what you learned from real users. Reusing the same structure also makes the phase-two quotation easy to compare with phase one and with other vendors if you decide to switch.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.

• Corporate Affairs Commission (CAC)
• Nigeria Data Protection Commission (NDPC)
• Paystack developer documentation
• Flutterwave developer documentation
• Apple Developer Program
• Google Play Console
• Node.js documentation