What you are actually buying when you pay for a mobile app
When somebody sends you a price for "a mobile app", that number almost always covers five separate things, and knowing what they are is the difference between reading a quote and guessing at one. The first is the iPhone app, the version people install from Apple's App Store. The second is the Android app, the version that comes from Google Play, which is a genuinely different piece of software even when it looks identical on screen. The third is the backend, which is simply a computer rented in a data centre that holds everything the apps need to remember: accounts, orders, bookings, photos and messages. The fourth is an admin dashboard, a private website your own staff sign into so they can see the orders, change the prices, answer customers and actually run the thing. The fifth is the two store listings, which is the paperwork and artwork side of it: the icon, the screenshots, the description, the privacy policy and the developer accounts that allow a company to publish at all.
Here is the frame the rest of this article rests on, because most price guides leave it out entirely. The build is a one time purchase, but the app you own afterwards behaves like a subscription. Phones change, and both operating systems get a major new version every single year on a schedule nobody consults you about, so an app that is left completely alone slowly stops working whether you spend money on it or not. That is not a story we tell in order to sell maintenance, it is simply how the two platforms operate, and it is the most expensive fact that owners tend to discover late.
This is written for the person deciding whether to spend at all: an owner, a director, a clinic manager, somebody with a budget and a hunch. It is not written for developers comparing tools, so every figure below is given in money and in weeks rather than in technical units. We are Linkysoft, and we spend our working weeks building mobile apps for businesses of exactly that size, which is where these numbers come from.
The three price bands we actually see, and what sits inside each
Across the projects we quote, prices cluster into three bands, and almost every enquiry we receive belongs to one of them once you strip the adjectives out of the brief.
Band one: a simple app
A catalogue people can browse, a booking or enquiry form, login, push notifications, and one small backend behind it. Roughly 8,000 to 25,000 USD, in 6 to 10 weeks from first meeting to store. This is the band for a restaurant, a gym, a clinic that wants appointments, or a shop that wants its loyalty card to live in a phone. It is a real app, it simply does not carry money or complicated rules.
Band two: a transactional app
Customer accounts, payments taken inside the app, staff with different levels of access, a proper admin dashboard, and behaviour that survives the signal dropping in a basement or a lift. Roughly 25,000 to 70,000 USD, over 3 to 5 months. Most serious business apps live here, because the moment money and staff roles are involved the amount of thinking behind each screen roughly doubles.
Band three: a marketplace or a regulated app
Two sides of users who have to find each other, such as customers and drivers or patients and doctors, plus live tracking on a map, chat between them, and an audit trail that records who did what and when. Roughly 70,000 to 200,000 USD and upward, over 6 to 12 months. Anything touching medical records, financial licensing or delivery logistics starts in this band, because the compliance work is a large slice of the build rather than a footnote at the end of it.
Now the part that confuses everyone. Send the same written scope to five companies and the quotes will come back three times apart, and all five can be honest. A mid size app is somewhere between 700 and 1,400 hours of work, and that part barely moves. What moves is the hourly rate, which runs from about 20 to 50 USD an hour at one end of the market to 90 to 180 USD an hour at the other, so multiply a thousand hours by either figure and the gap opens up on its own. What you buy at the higher end is usually seniority, testing depth, and the answer to a question owners never think to ask until the night it matters, which is who fixes it at two in the morning when payments stop going through. It is rarely raw talent, which means a cheap quote is not automatically a bad one, it is a different set of trade-offs that you should be able to name out loud before you sign.
Here is arithmetic you can repeat without us. Count the screens your app needs, and by screen we mean one distinct view a person lands on: the home screen, the product list, the product page, the basket, the checkout, the order history, and so on down the list. A finished screen, meaning designed, built for both phones, connected to the backend and tested, costs roughly 1,200 to 2,500 USD. So 30 screens lands between 36,000 and 75,000, which is exactly the middle band above. If the quote in your hand sits far below that, ask what has been left out, and if it sits far above it, ask what has been added. Doing this sum before you talk to anybody makes the conversation about budget shorter and a great deal less uncomfortable.
Where the money goes inside the build
Owners naturally assume that paying for an app means paying for the app, and about half the money goes somewhere else. On a typical build we plan against this split: design and user experience about 15 per cent, the two apps themselves about 40 per cent, the backend and its admin interface about 20 per cent, testing about 13 per cent, and project management about 12 per cent.
Read that twice and the uncomfortable point falls out on its own, because roughly half the budget buys things your customer will never see: the backend, the dashboard, the testing and the coordination. None of that is padding, it is the part that decides whether the app still works in month nine, but it does make one saving look very tempting. The saving people reach for is testing, since cutting it does not remove a single screen from the demo, and it is the most expensive cut on the menu. A bug found while the app is being built costs a fraction of what the same bug costs after launch, when it has to be diagnosed from an angry customer's description, fixed, retested, resubmitted to two stores and then waited on. We have never once seen a project save money by testing less.
The other thing that catches people out is the word "simple" in front of the word "screen". A screen is never one thing to build, because it has to behave properly in at least four situations: while it is loading, when there is nothing in it yet, when something has gone wrong, and when the phone has no signal. That empty state matters more than it sounds, because a brand new user opens your app to a list with nothing in it and decides within about four seconds whether the app is broken. So a list of 30 screens is really around 120 pieces of behaviour to design, build and check, which is precisely why the per screen price above is higher than most people expect.
One codebase or two, and what that choice does to the bill
There are two roads to having an app on both phones, and this choice moves the bill more than almost anything else in the quote. Native means writing two separate apps, each in the language its phone maker prefers, so an iPhone app and an Android app built independently of one another. Cross platform means writing one shared codebase, usually with a toolkit called Flutter or React Native, which then produces both apps out of the same work.
The money looks like this. Two native apps come to roughly 1.6 to 1.8 times the cost of one platform on its own rather than double, because the design and the backend are shared whichever road you take. A cross platform build typically saves 30 to 40 per cent up front, and, which matters far more across five years, roughly the same share on every change you ever ask for afterwards, since your developer changes one thing instead of two.
Native is genuinely worth paying for in a short list of cases: heavy camera or augmented reality work, talking to Bluetooth hardware such as a meter or a card reader, tracking location in the background all day the way a fleet app does, or a real game. Outside that list, for an ordinary business app made of accounts, lists, payments and notifications, cross platform is the right call, and we say so to clients even when the bigger build would have been the bigger invoice.
The sharpest saving of all is not technical at all. Launching on one platform first cuts the first invoice by about 35 to 45 per cent, puts the app in real hands months earlier, and lets you fix what you got wrong before paying to duplicate it. The platform you choose should be the one your customers actually carry, and you do not need a research budget to find that out: stand near your own counter for a day and look at the phones people are holding while they wait. That single day of watching is worth more than any national market share chart, because you are not selling to the nation.
The small bills nobody puts in the quote
There is a small pile of costs that almost never appears in a development quote, not because anyone is hiding them but because they are not development. They are still real money and they still leave your bank account.
Store accounts come first. Apple charges 99 USD every year for a developer account, and if you stop paying it your app comes down from the App Store. Google Play charges 25 USD once and never again, so publishing costs 124 USD in year one and 99 USD a year after that. The price is trivial, but the ownership is not: both accounts must be opened in your own company's name, with your company's bank and tax details, and never in the agency's. An agency that publishes your app under its own account is holding your app hostage without necessarily intending to, and untangling that later is genuinely painful.
Listing assets come next. Each store wants an icon, screenshots at several device sizes, a description in every language you support, a privacy policy sitting on a public web address, and a data safety declaration that explains what you collect and why. Both stores now also expect a route inside the app for a user to delete their own account, and missing it is one of the most common reasons a first submission is refused. Preparing that pack is a couple of days of real work, so it should be named in the quote rather than discovered during launch week.
Then come the setup costs that arrive once and surprise everyone. Onboarding with a payment gateway means paperwork and business verification, which takes anywhere from a week to three depending on the provider and your country. You need a domain and a certificate for the backend. You need real test devices, because an app that behaves perfectly on a developer's simulator can still fall over on a four year old phone with a cracked screen and two thousand photos on it. And somebody has to keep the signing key safe, which is the digital stamp proving an update really came from you, because if it is lost you cannot update your own app at all, only publish a new one and ask every customer to reinstall.
One more, since a good share of our work is for Arabic speaking clients. Supporting Arabic or another right to left language properly adds roughly 15 to 25 per cent to the design and testing lines, not to the whole build, because every screen has to be laid out mirrored and then checked again. Decided at the start, that is a manageable number you can plan around. Retrofitted after launch it costs several times more, since layouts written one way have to be unpicked one screen at a time.
What it costs to keep a live app running for a year
Here is the working rule we give every client before they sign anything: budget 15 to 20 per cent of the build price every year for maintenance. On a 45,000 USD app that is about 6,750 to 9,000 a year simply to stand still, before hosting and before a single new feature, and it is the line most quotes never mention.
The reason it is not optional is the yearly calendar the two platforms run on. iPhone and Android each ship a major release every year, and Apple also raises the minimum version of the toolkit apps must be built with roughly once a year, which means an app nobody has touched eventually cannot publish even a one line bug fix until several days of catching up have been done first. Meanwhile every outside service the app leans on changes its own rules on its own schedule. In practice, an unattended app starts visibly breaking for real customers within 18 to 24 months: a login that stops working on new phones, a payment screen that goes blank, a crash on the newest model that arrives in the same month your competitor's app does not crash.
Hosting is the other running cost, and it scales with people rather than with ambition, which is good news for almost everybody. Under about 5,000 people a month, running the backend and its database typically costs 40 to 150 USD a month. At about 50,000 people a month, with images and video moving around, that typically becomes 300 to 800 a month. Nobody pays the big number before they have the big audience, so this is one bill you can genuinely stop worrying about at the start.
Two quiet line items finish the picture. Crash and error monitoring, which is a service that tells you an app crashed on a customer's phone this morning instead of letting a one star review tell you in three weeks, costs around 50 USD a month. You also want backups and a staging copy, meaning a second private version of the whole system where every change is tried before real customers see it, which is a small hosting cost and an enormous saving the first time a change goes wrong.
Add those up and the first year after launch for a mid size app is about 13,000 USD: roughly 7,500 for maintenance and operating system updates, about 3,000 for hosting and the database, about 1,800 for outside services, about 600 for monitoring, and 124 for the two store accounts. If you want to see what that yearly work actually consists of month by month, our writing on maintenance goes through it in detail.
The costs that grow with your users, not with your code
Some costs have nothing to do with how your app was built and everything to do with how many people use it, and these are the ones that quietly wreck a budget that looked fine on paper.
Login codes sent by SMS are the classic case. A one time code costs roughly 0.02 to 0.09 USD per message depending on the country, and messages to some countries cost several times what they cost to others. If 5,000 people log in each month and each login takes two messages, because the first gets mistyped or arrives late, you are spending 200 to 900 USD a month on text messages alone. That is why we usually push clients toward login by email, or an authenticator app, or simply keeping people signed in for longer, and the switch often pays for itself inside one quarter.
Maps are metered the same way. If your app shows a map, draws a route or estimates a delivery time, you pay per use, and a delivery style app doing around 100,000 map loads a month commonly lands between 200 and 700 USD a month. That is manageable when you have planned for it and painful when the first invoice is a surprise.
Store commission decides something bigger than a price, which is whether payments belong inside the app at all. Apple and Google take about 30 per cent on digital goods, meaning anything consumed inside the app such as subscriptions, credits, coins or premium content. That falls to about 15 per cent for small businesses earning under a million a year, and for subscriptions after a customer's first year. Most importantly, they take nothing at all when you sell physical goods or services delivered in person, so a restaurant, a shop, a clinic or a plumber pays no commission on orders taken through their own app. Set that against card processing on your own website, which is roughly 2.9 per cent plus a small fixed fee per transaction, and you can see why an hour spent deciding where money changes hands is an hour well spent.
The last cost is human. At around 10,000 active users, expect 20 to 60 support messages a week: forgotten passwords, an order that never arrived, a refund, a bug on a phone model nobody in your office has ever held. That is a genuine part time job, so it belongs in the budget as a salary rather than as software, because no amount of good design makes it disappear.
When you pay, not just how much
Owners ask how much and then get caught out by when, so the cash flow is worth laying out honestly. A typical mid size project runs about 2 weeks of discovery, meaning the sessions where scope, screens and rules get pinned down on paper, then about 3 weeks of design, then 8 to 12 weeks of building, then about 3 weeks of testing and fixing, then 1 to 2 weeks of store submission. Payment normally leaves in four or five instalments tied to those milestones rather than in one lump, which is far kinder to a business's cash than a single invoice would be.
Store review is neither instant nor entirely predictable. Apple's review commonly completes within 48 hours, while Google Play often takes 1 to 7 days for a brand new app, because first releases get more scrutiny than updates do. In our practice roughly one first submission in three comes back refused, usually for something small and fixable such as a missing account deletion route, a privacy answer that does not match what the app actually collects, or a login the reviewer could not get past. That is normal rather than a disaster, but it does mean you should plan a two week launch window instead of a launch day, and you should certainly not book the launch event for a Thursday.
Hold 10 to 15 per cent of the budget as contingency, and hold it deliberately rather than hoping it turns up. The reason is arithmetic rather than pessimism, because a change requested after the design is signed off typically costs two to three times what the same change would have cost during design, when it was still a drawing rather than something already built twice, tested and wired into the backend.
All of which points at the single biggest lever on your total cost, and it is not the hourly rate you negotiate. It is the decisions made in the first three weeks, while changing your mind is still free. An owner who spends two extra days in discovery arguing about what the app does not need will save more money than one who spends two weeks arguing about the rate.
When the cheaper option is the right one, and we will tell you
Not every business that asks for an app needs one, and saying so out loud is part of the job.
A mobile friendly website or a web app, meaning a system people open in their phone's browser and use like an app without installing anything, often costs 30 to 50 per cent of a native build. It goes live in weeks rather than months, it needs no store review, no yearly developer account and no second version for the other phone, and it proves whether anybody actually wants the thing you were about to spend 45,000 on. For a large share of the enquiries that reach us, that is the honest first step, and our page on web application development sets out what that route covers.
If you do want an app, there are still two cheaper ways to begin. Ship on one platform first, as above, or run a pilot: build a deliberately small version, put it in the hands of 200 real customers for a few thousand dollars, and watch what they do with it. Both give you the one thing no quote can give you, which is evidence.
Then there is the blunt test, offered kindly. If your app is a form, a list and a login, your customers will not install it. People keep about thirty apps on a phone and they are not holding a slot open for a business they visit twice a year, so that idea should be a page on your website instead, where search will find it and somebody will use it the first time they need it.
Linkysoft has advised clients to spend less than they came in asking to spend, more than once, and the reasoning never changes. An app nobody opens costs exactly the same to maintain as one that earns, because the operating systems update on their own schedule regardless of your download numbers, so the maintenance bill arrives either way. The only question worth answering first is whether anybody will open it.
How to read a quote so you are not surprised in month seven
Most unpleasant surprises in app projects arrive in month seven, and nearly all of them were readable in the quote back in month one. Five questions get you most of the way there, and any developer worth signing with will answer all five in writing without flinching.
- What is explicitly excluded? The excluded list tells you more than the included one, and the usual absentees are content, translations, payment gateway paperwork and store assets.
- Who owns the source code and the store accounts? The answer should be you, in writing, with both accounts standing in your company's name from day one.
- What is the hourly rate for changes after launch? You will want changes by month four, so settle the number now, while your signature is still the thing they are waiting for.
- What happens when an operating system update breaks the app? Ask whether that is inside the maintenance fee or billed separately, because it will happen, and it will usually happen in September.
- Who holds the signing key, and where is the backup kept? If the answer is vague, that vagueness is the whole answer.
On fixed price against time and materials, which is the other question we get constantly, a fixed price is not free insurance. The contingency is already sitting inside the number you agreed, so you paid for it whether it was needed or not, and the developer will reasonably push back on anything outside the written scope. Time and materials means paying for the hours actually worked, which is cheaper while the product is still being discovered and riskier when nobody is watching the running total. Our rule is simple enough to remember: fixed price when the scope is tightly defined and you truly will not change it, time and materials when you know you are still working out what the product should be.
Insist that the first year of maintenance is priced in the same document as the build. If it is not, the real total is unknown at the exact moment somebody is asking you to sign, which is the worst possible moment not to know it.
Finally, ask what data the app stores, where it physically lives and who on the team can read it. An app holding customer names, phone numbers, addresses and payment references carries a real obligation, and a breach costs far more, in money and in the customers who quietly stop using you, than the review that would have prevented it. A short security review before launch is one of the cheapest lines in the entire project, so it is worth reading about security before you sign rather than after.
A five year total, worked end to end
Bands are useful, but one worked example is what people actually remember, so here is the shape of a project we could quote tomorrow morning.
A services business wants an app of about 30 screens: accounts, a catalogue, booking, payment, order history, notifications, and an admin dashboard for the office. Built cross platform, so one codebase feeding both phones, it comes to about 45,000 USD and takes around four months. After launch it costs about 13,000 a year to run, using the breakdown above. Over five years that is 45,000 plus 65,000, so roughly 110,000 USD in total, which means the build everybody argued about is only around 41 per cent of what the owner actually spends. That single sentence is the reason this article exists.
Now turn it into a decision you can make at your own desk in ten minutes. 110,000 USD across five years is about 1,830 USD a month, so the question is not whether an app would be nice to have, it is whether this app will earn or save more than 1,830 a month: in extra orders, in bookings that would otherwise have been missed, in staff hours that stop being spent on the phone, in repeat customers who come back because the reorder button is already in their pocket. If you can see a credible path to that number, build it. If you cannot, the honest answer is not to build it yet, and no amount of enthusiasm changes the arithmetic.
The same sum works in the small band, which is where a lot of readers actually sit. A 12,000 USD app costs about 4,000 a year to keep alive, so five years is roughly 32,000, or about 530 a month. A small clinic that fills four extra appointments a month has already cleared that, and so has a restaurant that keeps sixty orders a month off a delivery platform charging twenty five per cent. The band you are in matters far less than whether you did the sum at all.
If you would like your own number instead of a band, send us your screen list, or just a plain description of what the app should do and who will use it, and we will price it line by line and tell you frankly which lines we would cut. You can start that on our contact page, and if you would rather see the work before the conversation, our case studies show what these budgets bought in practice. Whoever you end up hiring, ask them for the five year number and not just the build price, because the five year number is the one that lands in your account. That is how Linkysoft quotes, and it is why our first conversation is usually about what you should not build.
