Scoping an app before you put a number on it

An app gets quoted badly for one simple reason: what the client describes is the screen, and what costs money is underneath it.

"An app where my customers book a slot" can be three weeks or six months. The sentence is the same. What follows is what makes the difference, and what has to be asked before a number is offered.

What it has to run on

The first question, and the one that gets skipped because it looks obvious.

A site people open on their phone, an app installed from a store, and an internal tool used at a desk are three different projects, with three costs and three timelines. The client says "app" for all three.

The distinction that costs most is the stores. Publishing is not exporting: it is a developer account, a review that can say no, rules that change, and an update that takes days to go out. If nobody mentioned it, nobody quoted it.

Accounts, and the real trap in roles

"People will need to log in" is a sentence clients say quickly. It adds a sign-up, a sign-in, a forgotten password, an address to verify, and somewhere to delete an account.

That is not the trap yet. The trap is the question after it: who sees what.

A role is a set of permissions. Two roles is already a matrix to hold in every screen, every button and every query. Three roles with exceptions is half the project. The client who answers "just an admin and normal users" answered quickly, and will add "oh, and the managers who see their own team" in the week you thought you were finished.

Ask it in the form that blocks the quick answer: list the kinds of people, and for each one, what they must not be able to see.

What it has to connect to

This is the question that rewrites a quote, because an integration is not a feature: it is a dependency on something you do not control.

A payment provider, a calendar, an invoicing tool, something the client already uses and mentions as if it were obvious. Each brings documentation to read, error cases to handle, credentials to obtain, and a possible outage that will never be your doing and always your problem.

Two details are worth their weight in hours:

• Who holds the credentials. A client who does not have the login for their own tool often takes two weeks to find it, and that is two weeks with the project stopped.
• Which way the data flows. Reading and writing are not the same work, and a client who says "sync" almost always means both.

Sensitive data, before rather than after

If the app handles health data, banking data, or personal data beyond a name and an email address, that changes the hosting, how long things are kept, what has to go in a privacy policy, and what the client has to be able to demonstrate.

This is not a technical question and it is not yours to settle alone. It is a question to ask early, because the answer moves architectural choices that stop moving once the project has started.

What already exists

One last question, the most profitable of all: does this replace something?

If it does, there is data to carry over, habits to respect, and users who will compare your work to what they know. A data migration is a project inside the project, and it is never in the quote when it was never asked about.

And if mock-ups, a sketch or a specification exist, even a bad one, you need to see them before quoting. A rough document says more about expectations than an hour of meeting.

The full list of questions this trade asks is here: the brief for an app or a piece of software. It is a starting point, to shorten and reword to the way you work.

And on turning work down cleanly when the answers do not come: when to turn down a project.

Frequently asked questions

What should you ask before quoting an app?

What it has to run on, whether it needs user accounts and which roles, what it has to connect to, whether it handles sensitive data, and what already exists. Those five answers close most of the gap between a quote and reality.

Why do user roles cost so much?

Because a role is not a setting: it is a rule to hold in every screen, every button and every query. Two roles are manageable. Three roles with exceptions are often half the work, and they rarely appear in the client's first description.

Should store publishing be in the quote?

Yes, and as its own line. Publishing needs a developer account, a review that can refuse, rules that change and update delays. It is not an export at the end of the project, it is a stage with its own risk of slipping.

What do you do when the client has no access to their own tools?

Find out early and write it down as a dependency. Recovering credentials often takes two weeks on the client's side, and the project cannot move meanwhile. An integration without access is not half built: it has not started.