How to Review an App Development Proposal
App proposals hide cost differently from website proposals. A website's cost mostly sits in pages and design. An app's cost sits in things that are invisible in a screenshot: the server that holds the data, the admin panel your staff will use, the payment reconciliation logic, the push notification infrastructure, the testing across dozens of Android devices, and the yearly work required to keep the app compliant with Apple and Google policy changes.
This guide shows how to read an app development proposal so that those invisible costs surface before you sign, and how to compare two or three quotes that look nothing like each other.
What an app proposal should contain
For any app project above roughly ₦1,500,000, expect the proposal to cover:
- The business objective and the primary user journey the app exists to serve.
- Platforms: Android, iOS, or both, and the technical approach (native or cross-platform).
- A feature list for this version, each feature described in a sentence.
- Backend scope: database, APIs, server environment, admin dashboard.
- Named integrations: payment gateway, SMS or WhatsApp, maps, email, analytics.
- Design deliverables: number of screens, prototype, revision rounds.
- Testing approach and the device list.
- Store submission: who publishes, under whose developer account.
- Timeline with milestones and your obligations.
- Price, split into one-off build and recurring running costs.
- Maintenance terms and rate after launch.
- Exclusions and assumptions.
- Ownership of source code, designs and accounts.
If the document does not mention a backend or an admin dashboard, either your app genuinely has no server side, or the proposal is incomplete. Ask which.
The first pass: eight quick checks
- Are both the app and the server described? Most business apps are really two products.
- Is there an admin dashboard? Someone has to manage orders, users, content or prices.
- Is the platform decision explained? "Android and iOS" at the same price as Android alone deserves a question.
- Are integrations named? "Payment integration" without a gateway name is not scoped.
- Is testing described? Device list, test types, who does user acceptance testing.
- Are store accounts addressed? Apple and Google accounts should be yours.
- Are recurring costs itemised? Servers, SMS, push services and any USD subscriptions.
- Is maintenance priced? Apps decay faster than websites; a missing number here is a future negotiation you will lose.
Platform strategy: what is actually being built
The platform decision drives a large share of the cost, so the proposal should justify it rather than assume it.
| Approach | What it means | When it fits | Cost implication |
|---|---|---|---|
| Android only | One native or cross-platform build for Android | Mass-market Nigerian consumer audience, price-sensitive users | Lowest initial cost |
| iOS only | One build for iPhone | Premium, urban or diaspora audiences; internal apps on company iPhones | Similar build cost to Android, smaller local reach |
| Cross-platform (Flutter, React Native) | One codebase producing both apps | Most Nigerian SME apps; standard business features | Usually cheaper than two native builds, one team |
| Two native builds | Separate Swift and Kotlin codebases | Heavy device-level features, very high performance needs | Highest cost, two maintenance streams |
| Progressive web app | A web app installable from the browser | Low budget, content or ordering, no store presence needed | Lowest cost, no store review, limited device features |
If the proposal recommends two native builds, ask what specifically requires them. For the large majority of Nigerian business apps, cross-platform is the pragmatic answer, and a firm should be able to explain the trade-offs. Native vs Cross-Platform App Developmentrian Businesses go deeper.
Also check whether an iOS build assumes you have a Mac, an Apple Developer Program account and someone able to manage signing certificates. Those are real, recurring administrative tasks.
The parts buyers forget to price
These items regularly appear as "extra" after signing. Confirm each one is in or out before you agree the price.
- Backend and database hosting. A cloud environment for an app typically runs ₦150,000–₦800,000 or more per year, depending on traffic and storage, and is usually USD-denominated.
- Admin dashboard. A proper web dashboard with roles, search, filters and reports is a project in itself, often 20–30% of the build.
- Push notifications. The infrastructure is usually free or cheap, but the logic for segmenting and scheduling messages is development work.
- SMS and OTP. Per-message charges add up quickly for verification flows. Ask for an estimate at your expected user volume.
- Payment reconciliation. Handling pending, failed and duplicated transactions, refunds and settlement reporting is more work than the checkout screen.
- Analytics and crash reporting. Without them you cannot tell why users leave or why the app crashes.
- App store assets. Screenshots, descriptions, privacy policy, store listing copy.
- Content and data loading. Somebody must enter the initial products, prices or records.
- Post-launch maintenance. Indicatively 15–25% of build cost per year, covering operating system updates, store policy changes, library upgrades and bug fixes.
Reading the feature list
Insist that each feature is a sentence, not a noun. Compare these two lines from real-world proposal styles:
- Weak: "User management."
- Strong: "Users register with a phone number, verify by SMS OTP, set a PIN, and can reset the PIN by OTP. Admin can suspend or delete an account and see the last login."
The second version can be estimated, built, tested and accepted. The first cannot.
Apply the same test to the features Nigerian business apps most often get wrong:
- Payments. Which gateway, which methods (card, bank transfer, USSD), what the user sees when a transfer is pending, how refunds work, and who reconciles.
- Delivery or logistics. Whether the app calculates fees by zone, integrates with a courier, or simply records an address.
- Offline behaviour. What the app does when the network drops mid-transaction. In Nigeria this is not an edge case.
- Data usage. Image sizes and caching strategy. An app that re-downloads large images on every screen will be uninstalled.
- Roles. Customer, staff, branch manager and administrator are four different products inside one app.
- Notifications. Push, SMS or WhatsApp, and which events trigger which channel.
Ask the firm to mark each feature as in scope for version one or deferred. A proposal that defers nothing has usually not thought about sequencing.
Testing, devices and quality
Testing is the easiest section to cut when a firm is competing on price, and the most expensive omission.
A credible proposal states:
- The device test matrix: a list of Android devices and versions, plus iPhone models. Nigerian users run a wide spread of budget Android phones, so testing only on a recent flagship is not testing.
- Network conditions tested: full signal, weak 3G, and offline.
- Test types: functional, payment end-to-end with a real test transaction, security basics, and performance.
- Who performs user acceptance testing and how long you have to raise defects.
- The defect severity definitions and turnaround for each.
Mobile App Testing Checklistptance annex.
Store accounts, publishing and ownership
Three things should be non-negotiable.
The developer accounts belong to your business. The Apple Developer Program is a yearly fee, historically US$99 per year, and Google Play developer registration is a one-time fee, historically US$25; verify current fees with Apple and Google. Register both in your company's name with your company email. If the app sits under an agency's account, you cannot transfer it easily, and you lose the reviews and install base if the relationship ends.
The source code is delivered as you go. Ask for a repository in your organisation's account, with the firm added as a collaborator, and code pushed at each milestone. This protects you far better than a clause promising delivery at the end.
The backend and third-party accounts are yours. Cloud hosting, payment gateway, SMS provider, analytics and error tracking should all be registered to your business. How to Own Your App Source Code.
Also check that the proposal accounts for store review. Apple in particular rejects apps for reasons that are hard to anticipate, and the proposal should say who handles resubmissions and whether that work is included.
Reading the price and the running costs
Compare the indicative figure in the proposal with the general bands for Nigerian app projects.
| App complexity | What it usually includes | Indicative build range |
|---|---|---|
| Simple MVP | One user type, a few screens, basic backend, no payments or simple payment link | ₦1,500,000–₦5,000,000 |
| Medium | Accounts, payments, admin dashboard, notifications, a second user role | ₦5,000,000–₦15,000,000 |
| Complex | Marketplace, fintech, multi-role, real-time tracking, heavy integrations | ₦15,000,000–₦50,000,000+ |
Indicative 2026 ranges; actual quotes vary with scope, vendor, platform choice and exchange rate.
Then build the twelve-month running cost yourself:
| Running cost | Indicative annual figure |
|---|---|
| Cloud/backend hosting | ₦150,000–₦800,000+ |
| Apple Developer Program | US$99 per year (verify current fee) |
| Google Play registration | US$25 one-off (verify current fee) |
| SMS/OTP usage | Volume-based; request an estimate |
| Maintenance and support | 15–25% of build cost per year |
Indicative; USD items move with the naira exchange rate.
A build quote that is 40% below the band for its complexity is not usually a discount. It normally means the backend, the admin dashboard, testing or maintenance has been left out, or that the team is smaller and less experienced than the timeline implies. Ask which, politely and directly.
Milestones and payment structure
| Milestone | Deliverable you can inspect | Indicative payment |
|---|---|---|
| 1. Kick-off and discovery | Signed scope, screen list, project plan, repository access | 20–30% |
| 2. Design approved | Clickable prototype of all screens on your phone | 15–25% |
| 3. Core journey working | Installable build completing the main flow with a real test payment | 25–30% |
| 4. Feature complete and tested | Build passing the agreed device matrix, ready for acceptance | 10–20% |
| 5. Store launch and handover | Apps live, code, documentation, credentials transferred | 10–20% |
The important structural point is that milestone three gives you a working app on a real phone before more than about half the money has moved. If a proposal's schedule does not let you hold a working build until late, negotiate it.
Example (hypothetical): three quotes for a Lagos pharmacy app
This is a hypothetical illustration, not a Linestech client project.
A pharmacy chain in Lagos with four branches wants an app where customers browse products, upload a prescription photograph, pay, and choose delivery or branch pickup, with an admin dashboard for staff.
- Quote A: ₦2,400,000, ten weeks. Android only, "payment integration" unnamed, no admin dashboard mentioned, no backend hosting line, no testing section, maintenance not priced. Payment 70% upfront.
- Quote B: ₦8,900,000, twenty weeks. Flutter for Android and iOS, described backend with product, order and prescription modules, admin dashboard with branch-level roles, Paystack integration with a defined pending-transfer flow, device matrix of twelve Android phones and three iPhones, store accounts in the pharmacy's name, ₦420,000 estimated first-year cloud cost, maintenance at 18% of build per year, five milestones.
- Quote C: ₦14,500,000, twenty-six weeks. Two native builds, a loyalty programme, an AI symptom checker and delivery-rider tracking, none of which were in the brief.
Quote A is not a cheaper version of Quote B; it is a different, smaller product with the expensive parts omitted. Adding a dashboard, an iOS build, hosting and testing would move it into Quote B's territory anyway, but without the scope being agreed in advance. Quote C solves problems the pharmacy has not confirmed it has. The chain proceeds with Quote B and records the loyalty programme and rider tracking as phase two, to be re-estimated once the first version has real usage.
A scoring sheet for comparing proposals
Score each proposal 0 (absent), 1 (partial) or 2 (clear).
- Business objective and primary user journey restated
- Platform approach explained and justified
- Every feature described in a sentence
- Backend and database scope defined
- Admin dashboard specified with roles
- Integrations named with responsibilities
- Offline and poor-network behaviour addressed
- Testing approach and device matrix given
- Store accounts and code ownership assigned to you
- One-off and recurring costs separated
- Maintenance rate stated for year one and beyond
- Milestones tied to inspectable deliverables
- Exclusions and assumptions listed
- Comparable live apps you can install
Twenty-two or more out of twenty-eight is a proposal you can work with. Anything under fourteen should go back with questions before you compare prices.
Mistakes buyers make with app proposals
- Judging by screen designs. Designs are the cheapest part of an app to produce and the least predictive of delivery quality.
- Ignoring the backend. The server, the data model and the admin tools usually cost more than the app screens.
- Assuming "Android and iOS" costs the same as one. Even with a cross-platform codebase, iOS adds design adaptation, testing, certificates, an annual fee and a review process.
- Not budgeting year two. Apps require yearly work to stay compatible with new operating system versions and store policies. App Maintenance Cost in Nigeria.
- Letting the firm open the store accounts. This is the most common way Nigerian businesses lose control of their own app.
- Accepting "we will add it later" without a price. Later is when your negotiating position is weakest.
- Approving a feature list you have not sequenced. Build the journey that earns money first; defer the rest.
- Signing the proposal rather than a contract. What Should Be Included in an App Development Contract?not cover.
Conclusion
An app proposal is worth reading in reverse order: start with maintenance, running costs and ownership, then work back to the feature list. The sections at the end are where a project becomes expensive or becomes yours.
Normalise the feature list across firms, add twelve months of running costs to every build price, insist that store and cloud accounts are registered to your business, and hold a working build on a real phone before more than half the money has moved. Those four habits remove most of the risk in Nigerian app procurement.
If you have an app proposal to assess, or you want a written scope and an indicative range before approaching vendors, Linestech can review your requirements and set out what the build realistically involves.
Frequently asked questions
How do I compare a fixed-price quote with a time-and-materials quote?
Ask the time-and-materials firm for an estimated total with a stated range and the assumptions behind it, and ask the fixed-price firm what happens when the scope changes. Fixed price transfers risk to the vendor, which usually means a higher number and tighter scope control. Time and materials suits projects where requirements are genuinely uncertain, provided you cap spending per phase.
Should the proposal include a prototype before full development?
For anything above a simple MVP, yes. A clickable prototype of the main screens costs a fraction of the build and prevents expensive rework. If it is not in the proposal, ask for it as a separately priced first phase that you can approve before committing to the rest.
What if one firm quotes in US dollars?
Ask for the naira equivalent, the rate used and the validity period, and clarify who bears movement between signing and each payment. USD quoting is not unreasonable for firms whose own costs are in dollars, but the risk allocation must be written down rather than assumed.
How many revision rounds should be included?
Two or three rounds on designs is typical, with a defined process for further changes. What matters more than the number is the definition: a round should mean one consolidated set of feedback from your side, not an unlimited stream of individual messages.
Does a shorter timeline mean a better proposal?
Usually the opposite. A ten-week estimate for an app with payments, roles and a dashboard normally means testing and the admin side have been compressed or omitted. Ask what the timeline assumes about your response times, and whether it includes store review, which is outside the firm's control.
Should I pay for discovery separately?
Paid discovery is often good value. A two- to four-week discovery phase produces a screen list, a data model and a firm estimate, and lets you judge the firm's thinking before committing millions. Make sure the discovery output belongs to you and can be given to another firm if you do not proceed.
What documentation should the proposal promise?
At minimum: a technical handover document covering the architecture and environments, API documentation, deployment instructions, an admin user guide and credentials for every account. Ask for these to be listed as milestone-five deliverables rather than described loosely as "handover".
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.
