Variables for building an app from the ground up

"How much does an app cost?" is unanswerable in the same way "how much does a building cost?" is unanswerable. But the variables are knowable, and if you arrive at a quoting conversation having thought about them, you will get a better number and a better project.

1. Platform

Web, iOS, Android, or several. Each platform is roughly a full workstream, not a checkbox. A cross-platform framework shares a lot of the logic but not the testing, the store submissions or the platform-specific conventions. Decide by what the app must do: camera, background location, offline sync and heavy graphics push toward native; most transactional and content apps do not need it.

2. Feature depth, not feature count

A feature list is a poor estimating instrument because "user accounts" can mean an email and a password or it can mean SSO, roles, org hierarchies, invitations and an audit trail. Describe the hardest version of each feature you actually need. Ten shallow features are cheaper than three deep ones.

3. Integrations

The single most under-estimated line in any quote. Every external system brings its own auth, rate limits, sandbox quality and outages. Two integrations is normal; six is a project of its own. Ask any prospective vendor whether they have made real calls against the systems you named before they gave you a number.

4. How much design already exists

• Nothing. Add a design phase — but you get an interface built for your users rather than adapted from someone else's.
• Brand guidelines only. The efficient middle. Enough constraint to move fast, enough freedom to design properly.
• Complete designs. Fastest, provided they were drawn by someone who understands what is expensive to build.

5. Data and content

Migrating from an existing system is frequently larger than building the new one. Old data is messier than anyone remembers, and reconciling two systems that disagree about what a customer is takes real time. If you are migrating, get a sample export in front of your vendor before signature.

6. Compliance and privacy

HIPAA, GDPR, PCI, SOC 2 and accessibility requirements all change the architecture, not just the paperwork. They are dramatically cheaper designed in than retrofitted. Say them out loud at the first meeting even if you are not sure they apply.

7. Scale, honestly

Build for ten times your current traffic, not a thousand times. Over-engineering for imaginary scale is the most common way early-stage money disappears. Make the architecture easy to change instead of expensive to be right about.

8. Who maintains it

Software is not a purchase, it is a commitment. Operating systems change, dependencies get advisories, and browsers move. Budget for maintenance from day one or plan for a rewrite in year three — those are the only two options and one of them is much more expensive.

A shortcut

Write one page: who uses this, what they are trying to do, what happens today instead, and what has to be true for this to be worth the money. Any competent studio can quote from that page. If a vendor gives you a number without asking those questions, the number is fiction.