What to send before asking for a mobile app proposal

A useful proposal starts with four points: the users and their main task, the app's current state, the systems it must connect to, and your delivery constraints. A sentence or two for each is enough to start.

Cost and delivery time depend on the agreed scope. The brief helps identify that scope and the questions that need answering before an estimate.

This article explains what each part of the brief tells a delivery partner, what drives cost and delivery time, and what to leave out of a first message.

The four things to send

Who will use the app, and for what

Name the users and their main task. They may be customers, employees or partners. If there are several groups, say which matters most for the first release.

For example: “Field technicians record each inspection and sign it off on site.” That gives a delivery partner a concrete workflow to discuss.

First release or existing app

• First release: Say what already exists, such as research, designs, a web product or a prototype.
• Existing app: Describe the problem, current technology, source-code owner and whether the app can be built and released today. Include public store links.

An existing app's condition, build process and dependencies need assessment before a takeover is agreed.

The backend or API, and who is responsible for it

If the app connects to an existing system, name it, say what the API supports today and who can change it. That person matters as much as the API itself. If there is no system yet, say so: for a new product, what it needs on the server side is agreed as part of the scope. The article on what your API needs before we build a mobile app covers this in detail.

Platforms, priorities, timing and budget

Say whether you need iOS, Android or both, what matters most if trade-offs are needed, any date that is fixed for a real reason, and any budget constraints. A budget range is not a commitment; it helps shape a first release that fits within it.

A completed fictional brief

This fictional example shows the detail needed for a useful first conversation. It describes no client engagement or delivery commitment.

Company and users: Northline Services, a fictional maintenance company. About 35 field technicians would use the app. Dispatchers would continue to use the existing web system.

Core journey: A technician opens today’s assigned visit, records checklist answers and two equipment readings, adds optional photos, asks the customer to sign and submits the completed visit.

Existing systems and owner: The dispatch system already exposes an API for work orders and customer sites. Petra, the fictional client’s backend lead, owns API changes. Authentication and photo upload exist; offline submission, pagination and stable error codes still need to be checked.

Platforms and priorities: iOS and Android. The first priority is the completed-visit journey. The app must let a technician complete that journey without a signal and send it when the connection returns.

Excluded from the first release: Dispatch planning, invoicing, stock management, live technician tracking and a replacement for the existing web system.

Dependencies: Test accounts with synthetic visits; a test API matching the planned production version; a decision about conflict handling; Apple and Google organisation accounts owned by Northline Services; named people for acceptance and store release.

Timing and budget: No fixed launch date or approved budget yet. Northline Services wants an estimate after the offline behaviour and API gaps are understood. Both are written as unknowns rather than guessed.

Open decisions: Can a submitted visit be edited? How long may photos stay on the device? What happens when dispatch changes a visit while the technician is offline? Who supports the app after release?

This example gives a delivery partner enough information to identify the next questions. It does not pretend those questions have already been answered.

Copyable blank brief

Copy this into your own document or first message. Keep passwords, API keys and customer data out of it.

Company or product:
Users:
Main task in the first release:

First release or existing app:
What already exists:
Public links, if any:

Backend or API:
Person or team responsible for it:
Known API gaps:
Test environment available: yes / no / unknown

Platforms: iOS / Android / both
Offline tasks, if any:
Required SDKs or device features:

Included in the first release:
Explicitly excluded:
Dependencies on your team or suppliers:

Fixed date and its reason, if any:
Budget constraint or range, if available:

Open decisions and unknowns:
Person who accepts the work:
Person who owns store release:

How much will it cost, and how long will it take?

Every estimate comes down to the same factors:

• User journeys. How many tasks the app supports and how complex each one is. Approving a request is simpler than a multi-step application with a document upload.
• Design readiness. Whether screens and flows are designed and agreed, partly sketched, or still to be defined.
• API quality. Whether the API already covers each task, with sign-in and permissions enforced on the server, or needs changes first.
• Integrations. Payments, identity verification, maps, analytics or other third-party SDKs and services, each with its own requirements.
• Offline behaviour. Which tasks must work without a connection, and how changes are synchronised afterwards.
• Testing. The devices, OS versions and scenarios that need testing on both platforms, including any security or regulatory review your organisation requires.
• Release. Store accounts, review requirements, and who is responsible for each release and for the handover.

Keep the first release focused on the essential task. Define later improvements, maintenance and support separately.

If you are still deciding between one shared codebase and separate native apps, React Native for business apps explains which of these factors a shared codebase affects and which it does not.

Why an estimate needs an agreed scope

Two apps described in one sentence each can differ greatly in effort once the journeys, integrations and release requirements are known. That is why we estimate against an agreed scope rather than promise a standard price or launch date. The brief is the start of that scope; the conversation that follows fills in what the brief could not.

Write unknowns down. “We are not sure whether the API supports this” tells both sides what needs checking before they can rely on an estimate.

What to leave out

Please keep credentials, API keys and customer data out of the first message. They are not needed to discuss fit, and sending them by email creates a risk for you. Detailed internal documents can wait until both sides have agreed how they will be handled.

What happens next

A short summary is enough to start: send those four points through the contact page, a sentence or two each is fine. From there, we discuss fit, clarify the dependencies, especially the backend and any SDKs, and agree what is needed for a scope and estimate. The mobile app development page lists the same questions in shorter form.