What to send before asking for a mobile app proposal

The four points a useful mobile app brief covers, what drives cost and delivery time, and why an estimate follows an agreed scope, not a standard price.

A useful mobile app proposal starts from a short brief covering four things: who will use the app and the main task it should solve, whether it is a first release or an existing app, which backend or API it must connect to and who is responsible for it, and your platforms, priorities, timing and budget constraints. Cost and delivery time depend on scope, so a reliable estimate follows an agreed scope rather than a standard price or launch date.

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

Describe the users, whether customers, employees or partners, and the one task the app must help them complete. "Field technicians record each inspection and sign it off on site" gives far more to work with than "an app for our technicians". If there are several user groups, say which one matters most for the first release.

First release or existing app

For a first release, say what already exists: research, designs, a web product, a prototype. For an existing app, describe the problem you want solved, the current technology, who owns the source code and whether the app can be built and released from it today. Taking over an app depends on its condition, build process and dependencies, and those need to be assessed before the work is agreed. Public store links help.

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.

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.

A focused MVP limits the first release to the essential task, which keeps these factors under control. Later improvements and maintenance are defined separately, including what support is needed.

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.

Where something is unknown, write it down as unknown. "We are not sure whether the API supports this" is useful information. It tells both sides what needs checking before an estimate can be relied on.

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.