What to prepare before estimating a mobile app

Bring a clear task, not a finished technical document

You can ask for an app estimate while the idea is still taking shape. You do not need to choose a database or design every screen first. What the team needs is a believable picture of who will use the app, what they must finish and what your business already has in place.

The awkward part is usually not a missing feature list. It is a feature that means different things to different people. “Booking” might mean sending a request to an employee, reserving a live time slot or paying for the last available seat. An estimate based on the wrong interpretation can look precise and still be unhelpful. This guide shows how to prepare one useful page and what to expect in return.

Start with the person and the result

Write a sentence that could describe a real working day. “Existing students need to open their next lesson and send homework to their teacher” is a stronger starting point than “an innovative education ecosystem.” It gives the agency someone to design for and a result to protect.

Then explain what happens today. Perhaps students receive links in a group chat, teachers collect files by email and an administrator manually checks access. Those details reveal where the app should help. Without them, it is easy to automate the visible screen and leave the actual inconvenience untouched.

A first version should complete one valuable journey. It may not need recommendations, a community or advanced reporting yet. That is not an argument against ambition. It is a way to distinguish the product's first test from everything it might eventually become.

Replace a vague request with an observable journey

Consider a fictional class-booking service. The vague request is: “We want an app like a large fitness marketplace, with booking, payments and notifications.” A studio cannot tell whether you operate one venue or connect independent businesses, whether places are limited or how cancellations work.

A more useful request is: “Members of our first studio choose a class, reserve an available place, pay if their pass does not cover it and receive confirmation. Staff need to change the timetable and see who is attending. We are not adding independent venues or a social feed at launch.”

The second version is not a technical specification. It simply removes several expensive ambiguities. Add one exception: what happens if two people choose the last place, or if a payment succeeds after the reservation expires? The team can now identify a concrete investigation rather than guessing at a whole platform.

A one-page brief you can fill in

Use the following fields as a working draft. Short, honest answers are better than polished claims. Put “not decided” where needed, and name the person who can decide.

User and problem: [Who needs help, what they do today and what is inconvenient.]

First successful journey: [Where the person starts, what they choose or submit, and how they know it worked.]

Business operations: [Who prepares content, confirms actions, handles exceptions and answers customers.]

First release: [The functions required for that journey, with a separate sentence naming what is postponed.]

Existing systems: [Services to connect, their owners and whether documentation or test access is available.]

Design and content: [Idea, references, sketches or finished designs; who supplies text, images and translations.]

Launch conditions: [Countries, languages, iOS/Android, a real deadline and the reason for it.]

Open decisions: [The uncertainties most likely to change the plan, with an owner for each.]

Keep sensitive customer data and passwords out of the document. An example with invented names can explain the problem just as well. If the agency needs protected technical access later, arrange that separately.

Name the work that happens outside the app

The mobile interface is only one part of the service. If a customer can request a refund, someone must receive that request, decide what happens and update the record. If a teacher publishes a lesson, someone needs permission to upload, replace and withdraw it.

You do not need to design a full admin panel before asking for an estimate. Explain the staff actions and the consequences of a mistake. A receptionist who can change attendance may not need permission to change payment details. Our admin panel guide helps separate those responsibilities.

Also say what can remain manual at first. A daily export may be enough for a small pilot; a safety-critical notification cannot simply wait in an unattended inbox. Manual work is a scope choice, not a way to pretend the work does not exist. Give it an owner and a realistic response expectation.

Make external dependencies visible

Two apps with the same screens can have very different delivery risks because of the systems behind them. “Connect our CRM” is not enough if nobody knows who maintains it or whether it exposes the required information.

Do not paste production credentials into a brief to make it look complete. Share a public documentation link or the contact who can authorize access. If a provider is not chosen, say so. Comparing providers is legitimate work and should appear as an open decision.

Bring references with reasons

Two or three references can be enough when each includes a specific observation. “The class timetable is easy to scan” helps. “Copy this app” leaves the agency guessing which years of hidden development you expect to reproduce.

Show something you dislike as well. Perhaps a payment error gives no next step, or a student cannot find an unfinished lesson. These examples can explain priorities more quickly than a long list of adjectives. They are references for a decision, not instructions to copy someone else's design.

Be equally clear about your own materials. A Figma file may contain visual screens but no empty states or cancellation flow. An existing app may have valuable data and undocumented technical constraints. Say what is actually available, not simply “design ready” or “backend ready.”

Separate a deadline from a wish

Explain why the date matters. A course launch, a signed partner agreement and a personal preference are different constraints. Also name the work your team must finish: account verification, content, policy review, payment approval or feedback on designs.

The estimate should show these dependencies, not quietly assume they will arrive. If the deadline is fixed, ask which scope can be removed while preserving the main journey. Reducing the number of decorative screens will not solve a missing integration or an unresolved operating rule.

For commercial terms and calculation methods, use the development cost guide. This preparation page is about improving the inputs, not quoting a standard amount for every project.

Ask for assumptions, exclusions and the next decision

A useful response should tell you what the team has understood, which work is included, what is excluded and what still needs investigation. It should distinguish an early directional estimate from a delivery commitment based on reviewed requirements.

Ask the agency to identify the most fragile assumption. For example: “We assume the existing scheduling service can prevent duplicate bookings.” The next step might be a short technical check before agreeing the final plan. That is more helpful than hiding uncertainty inside a confident total.

Use the agency selection guide to compare replies. Give all candidates the same updated brief and circulate important clarifications equally. Otherwise you are evaluating their access to information as much as their ability to deliver.

Check whether your brief is ready to send

Read it as someone who has never met you. Can that person identify the first user, the main result, the business's part of the work and the biggest unanswered question? If yes, you probably have enough for a useful conversation. If not, another page of feature names is unlikely to help.

At Appfyl, the short project questionnaire lets you submit this starting information for review. It is an estimate request, not an instant calculation or a promise about delivery. You can also use the same one-page structure when speaking to another team.

When behavior needs to become more exact, move to the technical specification template. The brief explains the problem and boundaries; the specification explains what must happen and how it will be accepted. Keeping those purposes separate saves unnecessary paperwork.

Questions people ask