When people ask what an app costs, they're usually asking about the build, the one time cost to get it into the store. That's only part of the real number. Here's an example that shows where the rest of it actually goes.
A working example
Say you're building a booking app for a salon chain, customers pick a service, pick a time, and pay, built for both iPhone and Android, with push notifications for appointment reminders. The build itself, design through launch, is the number most people focus on and plan around.
What often gets missed is everything after launch. Apple and Google both charge developer account fees to keep your app listed. Your app needs hosting for its backend, the part that stores bookings and handles payments, which is an ongoing monthly cost, not a one time one. Push notification and payment processing services usually have their own fees too, often based on usage, so they grow as your app gets more customers.
The part that surprises people most
Both Apple and Google update their operating systems every year, and those updates occasionally break something in existing apps, a permission that now works differently, a design guideline that changed, a library that needs updating to stay compatible. Budgeting for a developer to check compatibility and make small fixes after each major OS update, usually once or twice a year, avoids the app quietly breaking for a chunk of your users without warning.
Bug fixes and small improvements
Even a well built app turns up small issues once real customers start using it in ways you didn't fully anticipate. Something that worked fine in testing behaves differently on an older phone model, or a screen flow that made sense to the team confuses actual customers. Setting aside a modest, ongoing budget for these fixes, rather than assuming the app is simply done at launch, keeps small issues from turning into customers quietly giving up on the app.
Roughly how to think about the split
As a general rule of thumb, and this varies a lot by app complexity, the first year's ongoing costs, hosting, store fees, service usage, and maintenance combined, often land somewhere around a fifth to a third of what the initial build cost. It's not a small side cost, it's a real part of the budget, and planning for it from the start avoids an unpleasant surprise six months after launch when something needs fixing and there's no budget set aside for it.
The honest takeaway
An app is closer to a car than a piece of furniture. The purchase price isn't the whole cost of owning it. Asking your developer what year one maintenance typically looks like, before you sign off on the build cost, gives you a much more complete and realistic picture of what you're actually committing to.