How much it costs to make an app depends on what it needs to solve: a time-tracking tool and a marketplace with payments and messaging are very different jobs. This guide explains the factors you need to define to request a comparable proposal with a clear scope.
We look at the features, integrations and technical decisions that have the biggest impact on the project, plus the recurring costs worth planning for from the start.
If you're in a hurry, skip straight to the summary table at the end. If you have ten minutes, stay: it'll save you some headaches.
How to define the scope of a custom app
The cost of a custom app depends on its features, platforms and integrations. To define it, it helps to distinguish these levels of scope:
- Simple app (catalog, customer profile and forms): priced according to the screens and flows it needs to cover.
- Business management app (login, admin, notifications and ERP integration): requires defining users, permissions and data flows.
- App with advanced features (payments, geolocation, chat and offline sync): each integration and its testing needs to be assessed.
- Marketplace or SaaS product with an app: the scope must cover the app as well as the backend, the admin panel and how the product will evolve.
The proposal should cover analysis, UX/UI design, development for the chosen platforms, backend, testing and publishing. Maintenance and new features should be itemized separately.
Before accepting a quote, check whether it includes design, backend, testing, publishing and access to the code. An incomplete proposal can leave essential work out of scope.
The six factors that drive the cost of a custom mobile app
An app that displays content is not the same as one that processes payments. In my experience, these are the factors that push the budget up or down the most.
1. Target platforms
Publishing on one platform or both changes the scope. Flutter and React Native let you share part of the development; native may be a better fit if you need graphics performance or very specific hardware access.
2. Backend and integrations
This is where people get surprised. An app that connects to your ERP (Holded, Odoo, Sage 50, Dolibarr), to Redsys (Spain's card payment gateway), to the Spanish Tax Agency (AEAT) for invoicing or to Veri*Factu (Spain's invoicing compliance system) adds up hours fast. Every well-built integration means reading documentation, testing, handling errors and maintaining it.
3. Design and user experience
Good custom mobile app design isn't cosmetic: it's what makes people use the app more than twice. Budget between 15% and 25% of the total for UX/UI if you want something you can show without apologizing.
4. Regulatory compliance
GDPR and the Spanish Data Protection Act (LOPDGDD) must be built in from the design stage. If you handle health data, data on minors or payments, include a legal and technical review and define its requirements before pricing.
5. Offline sync and real time
Making the app work without coverage and sync later, or adding real-time chat, multiplies backend costs. It's not a technical whim: it's real complexity.
6. The provider's team and location
Compare providers on the team's experience, accountability for the project and ongoing support. Ask for the proposal to state who does the development, how it's coordinated and what each phase includes.
How much it costs to make an app by type: four real-world cases
These four types of app show which requirements shape the scope:
Case 1: Dental clinic with a booking app
An appointment app for a clinic can include booking, access to patient history and reminders. The scope depends on the integration with its practice management system and on privacy requirements.
Case 2: Delivery app for a fruit and vegetable cooperative
A delivery app may need optimized routes, digital signatures, delivery photos and offline sync. The connection to the ERP and the users' actual mobile coverage shape its development.
Case 3: MVP for a sports equipment rental startup
In a booking MVP, the first version can be limited to the catalog, booking, payment and an admin panel. Further features are decided once usage has been validated.
Case 4: Real estate management platform with an app
A real estate platform with an app needs clearly defined roles, geolocation and connections with external property portals. The quote is built from those flows and from the team's needs.
The backend, the admin panel and analytics should be in the proposal from the start. Leaving them out can lead to scope creep during development.
Native, hybrid or web app: how it affects your app development budget
This technical decision has a big impact on cost. Here's a summary without unnecessary jargon.
Native development (Swift for iOS, Kotlin for Android)
Two separate codebases, two teams (or one team that knows both), two schedules. Expensive, but it delivers the best performance. It makes sense if your app needs heavy graphics, augmented reality or very specific hardware access. For 80% of Spanish SME use cases, it's overkill.
Hybrid development (Flutter, React Native)
Flutter and React Native let you share code between iOS and Android. They can be a good option when the features allow it, although certain native integrations require specific modules.
Progressive web app (PWA) or web app
If your app doesn't need to be in the app stores and your users access it from a browser, a custom web application built as a PWA can save you between 40% and 60% compared with a native or hybrid app. It isn't always viable, but when it is, it's the smart move. For internal business tools, the web almost always wins.
My rule of thumb: if you need to be in the app stores because users will search for your app by name, go hybrid. If the app is internal, for employees or partners, consider a PWA. If you're building a game or something with high-performance camera features, go native, no question.
Hidden costs almost nobody mentions before you sign
Quotes usually cover development and little else. But over the first year, other costs crop up, and it's worth knowing about them in advance so they don't catch you off guard.
- Apple developer account: check the App Store's publishing and renewal terms.
- Google Play account: check the current terms for registering the account and publishing.
- Backend hosting and servers: these need to be sized for the traffic, storage and availability you need.
- Third-party services: payment gateway (per-transaction fees), push notifications (Firebase is usually free up to a certain volume), SMS, maps (Google Maps charges per use).
- Maintenance: agree on incident coverage, iOS and Android updates and ongoing feature development.
- Legal updates: changes to GDPR, cookie rules or electronic invoicing. In 2026, with Spain's mandatory e-invoicing advancing for freelancers and limited companies, keep this in mind if your app issues or receives invoices.
Assess corrective maintenance, system updates and new features separately. Ask for the proposal to detail the coverage and terms of each service.
How to request a quote without getting ripped off (or ripping off your provider)
Having seen a lot of sales processes, here's what I think separates a reliable quote from one that will blow up halfway through the project.
Do your homework
Don't ask for a quote with I want an app like Uber Eats, but cheaper. At the very least, define who it's for, what problem it solves, the five must-have features, which systems it needs to integrate with and which platforms it will run on. If you're not clear on it, your provider will be even less so.
Ask for a functional analysis before development
A functional analysis up front should pin down screens, business rules, integrations and acceptance criteria. Agreeing on that work reduces scope disputes during development.
Insist on code ownership and repository access
Your app should be yours. Ask for an IP assignment clause in the contract and access to the Git repository from day one. If they push back, that's a bad sign.
Payment milestones, not a single payment
A healthy structure: 30% on signing, 30–40% midway through the project against visible deliverables, and the rest on completion. Steer clear of 100% upfront, and also of 100% at the end (that may look good for you, but no serious provider accepts it, except on very small projects).
A good agency will tell you what not to do. If they say yes to everything, it's going to cost you.
Compare, but with judgment
Get three quotes. If one is far lower, ask what's missing. If one is far higher, ask what it includes that the others don't. The middle price is usually the realistic one.
Timelines: how long it takes to get your app up and running
Time is money, so it also affects the budget. As a guide for 2026:
- Simple app: 6–10 weeks from kick-off.
- Mid-complexity app: 3–5 months.
- Complex app with several integrations: 6–9 months.
- SaaS platform or product: 9 months or more, with iterative releases.
One important point: if you need to get to market fast, plan a six-week MVP with the bare minimum, then iterate. Launching earlier with less is usually better than launching late with everything. I see it all the time: teams spending eight months polishing features their real users don't want.
And watch out for artificially short timelines. If an agency says it can deliver a complex app in six weeks, either it already has 80% of the work done for another client (with all the problems that implies), or it won't make it. App store reviews can take three to ten days, and money can't speed that up.
The useful question is what problem the app needs to solve and how you'll check that it does. A well-focused first version can deliver more value than a broad, unvalidated platform.
Start with the essentials, measure usage and decide on the next phases based on data. Ask for a breakdown by module, repository access and clear maintenance terms.
And if you decide to go ahead, use the first meetings to define the scope properly. An hour of good conversation with the technical team saves weeks of rework later.