How much does it cost to build an app? What the price depends on

‘How much does it cost to build an app?’ is the question we’re asked more than any other. We wish there were a straight answer, but there isn’t. It’s a bit like asking what a house costs, or how long a piece of string is.

That doesn’t mean the price is plucked out of thin air. What a house costs depends on its size, the ground it stands on and whether it has a basement. What an app costs depends on what it has to do, which other systems it talks to and who uses it. You can answer those questions yourself before you talk to any supplier, and once you have, the quotes you get are easier to make sense of and compare.

Why an app is bigger than its screens

When you picture an app, you probably picture its screens: the home screen, a list, the button that does something. They’re quick to sketch, which is exactly why the app feels smaller than it is. The time usually goes on what sits behind them:

• A server to store the data and share it between users and devices.
• Accounts and a way to log in.
• Connections to systems you already have, such as the ERP (the system behind your orders, stock and invoicing), the CRM (where you keep track of customers) or the booking system.
• An admin interface, a back office where your staff manage content and answer customers.
• Everything around it: security, permissions, backups, monitoring and getting the app into the stores.

Say you have two apps with exactly the same screens. One just shows what’s stored in the app itself. The other fetches each customer’s orders from your ERP and takes payment through Swish, Sweden’s mobile payment service. The prices can be miles apart. It’s the same house from the street, one with a basement and one without.

What decides the price

A handful of questions decide what an app costs, and ‘I don’t know’ is a useful answer to any of them, because it tells you where the uncertainty is.

Does any data need to leave the phone?

If everything happens on the phone itself, the app doesn’t need a server. Say it’s a calculator, or a checklist one person uses on one phone. Now say the list has to be shared between two people, show up on more than one device, or still be there when you get a new phone. Then the data needs somewhere to live, and that usually means a server: a database, an API (an agreed way for one piece of software to talk to another), hosting, backups and someone keeping it running. A server costs money to build, and keeps costing money once it’s live.

Do people need an account, and how do they log in?

An account sounds like a sign-up form and a login screen. But then what? People forget their passwords and change their email addresses, and they have to be able to close their account and have their data deleted. If the app handles personal data, GDPR (the EU’s data protection rules) applies, and you need to know what you store, why and how long you keep it. If the app can do its job without accounts at all, that’s one of the biggest savings you can make.

If you need accounts, decide how people log in. Email and password is the simplest login to build, but it isn’t always the easiest one for your users. Logging in with Google or Apple spares people yet another password. BankID, Sweden’s most widely used e-ID, is the usual choice when you have to know who the user really is. It needs an agreement, though, and comes with ongoing fees. If staff log in with their work account, the app has to connect to the company’s own sign-in service. Sure, you could offer the lot. But each method is a separate thing to build and test, so pick the ones you need.

Which other systems does the app have to talk to?

Connections to other systems are usually the biggest uncertainty in an app’s price. Fetching orders from the ERP, taking bookings through the booking system or sending customer details to the CRM can cost very different amounts, depending on the system at the other end. If that system has an API and it’s well documented, so a developer can read how to connect to it, the job is usually quicker. If it has no API at all, or one nobody has used in years, that one connection can end up as the largest piece of work in the project. So before you ask anyone for a price, find out which systems are involved and whether they’re documented.

Does the app take payment?

Taking payment in the app means agreements first: card payments need one with a payment provider, and Swish needs one with your bank. Then purchases, refunds and receipts all have to be built into the app. If your app is in the App Store or Google Play and sells digital content, the store’s rules can require you to use its own payment system and pay the fee that comes with it. That changes what the app costs to build, and how much of each sale you actually keep.

Who keeps the content up to date?

If your staff will be editing text, adding products, handling requests or looking at the stats, the app needs an admin interface. It often gets forgotten in the first estimate, and it can grow to be as big as the app itself. An off-the-shelf tool can sometimes handle the content. If not, that’s one more thing to build.

Where does it run, and what does it need from the phone?

Which platforms the app runs on, and what it needs from the phone, decide which technology fits and how much has to be built separately for each platform. iPhone, Android, the web or all three? Does it need to work offline, send push notifications, use the camera or Bluetooth? Each answer moves the price.

Which rules apply to you?

Some of an app’s price comes from requirements you have to meet, not features you choose. Data about health, personal finances or children has to be protected to a higher standard. If your service is covered by accessibility requirements, it has to work with screen readers, which read the screen aloud, and with screen magnification, among other things. It’s cheaper to build a requirement in from the start than to add it after launch.

The cost carries on after launch

An app goes on costing money after launch, even if you never add another feature. Back to the house: it isn’t finished the day you move in. The gutters need clearing every autumn, the roof needs checking and the walls need repainting, whether or not you ever build an extension. An app is no different.

The operating systems on iPhones and Android phones get new versions every year, and the app stores tighten their requirements. The app’s libraries, the ready-made code it’s built on, get security updates. If there’s a server, someone has to keep it running. Those are the app’s gutters. So ask what it costs to run each year, not just what it costs to build. We’ve written more about what that upkeep involves.

How to get quotes you can compare

Getting a price you can compare starts with the problem, not a list of features. That means knowing who is going to use the app, what they need to get done and how you’ll know it’s working. Then ask whether the app needs building at all. If something off the shelf already does the job, that’s usually the cheaper route. If not, write down what the first version has to do and what can wait. Aim for the smallest first version that really solves the problem, not the biggest one the budget will stretch to.

With that on paper, a supplier can give you a range rather than a guess, and write down what it’s based on: which systems are covered, how login works and what’s left out. Anything still unknown, like a connection nobody has tried yet, can be tested on a small scale before anyone prices the whole project.

A price that doesn’t spell out its assumptions is a guess. Write them down and you have a price you can actually discuss.

When two prices differ, it’s often because the assumptions do, so compare those first. And if someone offers you a fixed price before asking any of this, ask what they’ve assumed and what happens when something turns out bigger than expected. There’s a separate article on what an estimate covers.

What to bring when you ask what an app costs

You won’t have an answer to every line, and you don’t need one. But with the list in front of you, the first conversation is about your app rather than how long a piece of string is.