In the Spanish market, a well-scoped first version of an app usually starts from around €5,000, and most custom work falls between roughly €5,000 and €50,000+. Where yours lands depends on what the first version does, not on it being “an app”.
These are market ranges, the same ones in our custom software cost guide. They are not SEIRO prices: we don’t publish rates, and every serious project is priced after the scope is agreed.
This piece explains what sits inside that range: the parts of an app you don’t see, what raises the price, when a native, cross-platform or web app makes sense, what it costs after launch, and how to get quotes you can compare.
Three kinds of app, three parts of the range
Almost every app we hear about fits one of these three. They help you place yourself before you ask for quotes, not to fix a price.
- A simple app: one kind of user, a few screens, no payments or integrations. For example, an app for your customers to book or check something. It sits near the bottom of the range.
- An app with accounts, payments and an admin panel: sign-up, in-app payments, notifications and an admin panel for your team. This is the most common, and it sits in the middle.
- A platform: several roles (customer, professional, admin), web and mobile sharing the same accounts, and integrations with your ERP, CRM or payment provider. It sits at the top, and often above €50,000.
The parts of an app you don’t see (but pay for)
When you picture an app, you picture the screens. But the screens are the visible part of a bigger system. An app that really works almost always needs:
- Backend and database. The servers that store users, orders or bookings, and keep the phone and the web in sync.
- Admin panel. Where your team manages users, content and orders without calling a developer.
- Accounts and security. Sign-up, login, password reset and permissions. With personal data, GDPR compliance too.
- Notifications. Push notifications on iOS and Android, and often email as well.
- Publishing to the stores. Preparing the listing, passing Apple’s and Google’s review, and fixing what they ask for.
Many cheap quotes only count the screens. The rest turns up later as “extras”. When you compare, ask which of these are inside the price.
What raises the price of an app
The number of screens matters less than you’d think. What really moves the price:
- User roles. Each kind of user (customer, professional, admin) adds screens, permissions and edge cases. A marketplace has at least two sides plus yours.
- Payments. Charging in the app, subscriptions, refunds and invoices. Apple’s and Google’s payment rules count too.
- Integrations. Connecting to your ERP, CRM, accounting or an outside provider. Each system adds work and maintenance.
- Phone features. Camera, live location, Bluetooth or working offline. They cost more than a normal screen.
- Platforms. iOS only, iOS and Android, or iOS, Android and web. Each one adds cost, though it doesn’t multiply it when code is shared.
- Unclear scope. “An app like Uber” isn’t a brief. Without agreeing what the first version does, the real cost shows up halfway through.
Native, cross-platform or web app
It’s one of the decisions that changes the budget most, and there’s no single answer.
A native app is built separately for iOS and for Android. It gets the most out of the phone, but that’s two codebases to maintain. A cross-platform app shares most of the code between the two, and usually costs less. A web app runs in the browser, skips the stores, and can be enough if the app doesn’t need phone features.
The choice depends on what the app needs from the phone, how fast it must feel and who will maintain it. On the first call we recommend one, with the reasons. And if a web app would do the job for less, we tell you.
The differences in more detail (performance, phone features, maintenance and the stores) are in our guide to native, cross-platform and web apps.
What it costs after launch
The build is only the first part. A live app keeps costing:
- Developer accounts. Apple charges a yearly fee to publish on the App Store, and Google a one-off fee for Google Play.
- Servers and services. Hosting for the backend and database, plus outside services such as maps, SMS or email. These usually grow with your users.
- Store commissions. If you sell digital content inside the app, Apple and Google take a percentage.
- Updates. New versions of iOS and Android come out every year. An app nobody maintains ends up breaking or disappearing from the stores.
- New features. What you left for version 2, once users tell you what’s missing.
Always ask what the quote covers after launch, and what maintenance costs. A quote that doesn’t mention it isn’t cheaper: it leaves it for later.
How long it takes to build an app
It depends on the scope, like the price. But the time almost always splits into the same five phases. Knowing them helps you understand a timeline, and spot one that doesn’t add up:
- Scope: what the first version does, who uses it and what’s left out. It’s the shortest phase, and the one that saves most time later.
- Design: the screens and how you move between them. Each kind of user adds screens to design.
- Build: the app, the backend and the admin panel, together. It’s the longest phase. It happens in short steps, so you see the app working as it’s built.
- Testing: on real iPhones and Android phones, with every change. Leave it to the end and the timeline stretches right before launch.
- Store review: Apple and Google review the app before it goes live. Apple usually answers in a day or two; Google can take several days, especially with a new developer account. If they ask for changes, you fix them and resubmit.
What stretches a timeline most is rarely the coding. It’s the waiting: decisions that slip, content that isn’t ready, or an outside provider (the payment gateway, the ERP) slow to give access.
A real example: a private, invitation-only members’ platform that already worked on the web. We redesigned the web app, reinforced its security and built it as a native iOS and Android app on the same accounts and data. It took four weeks of work.
Testing: where cheap quotes cut
Apps break in small places: a screen nobody opened, a button that does nothing, a flow that only fails on Android. Testing all of that by hand takes a long time, and it’s the first thing cut to bring a quote down.
We built our own AI automation technology that walks every screen and every button of the app. It cuts testing and bug-fixing time by up to 80%, and then an engineer checks every change. So the saving doesn’t come from testing less. In the Edge Log we explain how we built the testing agent, and how we measured it.
How to lower the price without a worse app
The best way to lower the price isn’t a cheaper vendor. It’s a smaller first version. To decide what goes in, read how to scope your MVP without building too much.
- Write what the app does in one sentence: “A [user] [does something] to [get something].”
- Take out of the first version everything that sentence doesn’t need.
- Replace the expensive parts with something manual at first: a bank transfer, an email alert, a simple panel.
- Start with one platform if you can: iOS only, Android only, or a web app.
- Decide how you’ll know it works: users who come back, or who pay.
Red flags in an app quote
A low price isn’t always a trap. These signs deserve a question:
- It only talks about screens, with no backend or admin panel.
- It doesn’t include publishing to the App Store and Google Play.
- It says nothing about testing, or about who reviews the code.
- It isn’t clear that the code and the data are yours.
- It doesn’t mention maintenance or iOS and Android updates.
- It arrives without a single question about your users or about what’s left out.
How to get quotes you can compare
If three vendors give you three very different prices, it’s almost always because they understood three different apps. Before asking for quotes, send everyone the same thing: what the first version does, who uses it (and how many roles), which platforms, which payments and integrations, and what’s left out.
Then the quotes are about the same app. For the market price bands in general, and fixed budgets versus hourly billing, read our custom software cost guide.
The next step
For a quick range, the calculator gives you an approximate estimate. It isn’t a quote or a SEIRO rate.
To know whether your app is worth building, and how, book a free 15-minute call. We talk about the idea, who will use it and whether an app is the right answer. Then we agree the scope and the budget, before any code.
Frequently asked questions
How much does it cost to build an app in 2026?
As a guide to the Spanish market, a well-scoped first version of an app usually starts from around €5,000, and most custom work falls between roughly €5,000 and €50,000+. A simple app sits near the bottom; a platform with several roles, web and mobile, and integrations sits at the top. These are market ranges, not SEIRO prices.
How much does an app like Uber cost?
An app like that is a platform: several roles, payments, live location and an admin panel. It sits at the top of the range or above. Almost nobody starts there: you start with the smallest version that proves the idea works.
Is a cross-platform app cheaper than a native one?
Usually, because it shares most of the code between iOS and Android. But it isn’t always the best choice: it depends on what the app needs from the phone and how fast it must feel.
How much does it cost to maintain an app?
It depends on the app and its users. Plan for Apple and Google developer accounts, servers, outside services, and updates for each new version of iOS and Android. Always ask what the quote covers after launch.
How long does it take to build an app?
It depends on the scope. As a reference, we built a private members’ platform as a native iOS and Android app in four weeks of work. Add the App Store and Google Play review.
Can I start with a web app instead of a mobile app?
Yes, if the app doesn’t need phone features such as background location, Bluetooth or heavy camera use. A web app skips the stores and usually costs less. Later you can build the mobile apps on the same accounts and data.