Decide what your mobile app has to run on before you ask anyone to price it
Two proposals for the same idea can differ by a factor of several simply because one assumed a single platform and a recent handset, and the other assumed both platforms plus older devices still in daily use. Nobody is lying. They answered a question you did not ask. The platform and device decision is the single largest lever on the cost of a mobile app, and it belongs to you rather than to the supplier.
Start from evidence you already hold. Look at the device and operating system split in your existing web analytics, at the handsets your support team sees in tickets, and at who your users are. A workforce tool for field staff on company issued phones is a narrow target. A consumer product aimed at a wide public is not, and in this market it means supporting a long tail of older Android hardware that never gets replaced because it still works.
Native, cross platform, or something the browser can install
Native mobile app builds give the best access to hardware, the smoothest interaction, and the least drama when the platform changes underneath you. Cross platform frameworks share most of the logic between the two stores and genuinely save money on interface heavy products, at the cost of a thin layer that occasionally has to be written twice anyway. An installable web build avoids the stores entirely, which is attractive until you need reliable push delivery, background work, or a payment flow users recognise.
The honest way to choose is by listing the three or four features that carry the product and asking what each approach costs for those specific features. A supplier with a single answer for every client is describing their own staffing, not your problem. Ask directly which parts of your requirement would still be written separately for each platform under a shared codebase, because that is where cross platform estimates usually slip.
The test fleet is a real line in a Barcelona quote
A mobile app that works on the developer's phone is not a finished product. Someone has to try it on a small screen, on a device several generations old, on a slow connection in a basement, with the system font enlarged, and with the battery saver switched on. That work needs actual hardware, or a paid device cloud, and it takes time from people who are not the cheapest on the team.
When you read a quote, find the testing line. If there is not one, ask which devices are covered and what happens when a bug only appears on a handset nobody owns. Also ask how a release is rolled out: a staged rollout that reaches a small share of users first, with a way to halt it, is the difference between a bad build affecting a few people and a bad build affecting everyone before lunch.
Language choices reach further than the interface
Barcelona is a bilingual city with a wider Spanish speaking audience behind it, and a mobile app has several separate language surfaces: the interface, the notification text, the store listing, the support material, and any content served from your systems. They are usually handled by different people and often by different budgets. Deciding late means retrofitting, and retrofitting a layout for longer strings is tedious work that gets charged at full rate.
Decide at the start which languages ship first, who supplies and reviews each string, and whether the app follows the phone setting or offers its own switch. If you plan to sell beyond this market later, say so now. Designing for one language and adding others afterwards is the most common cause of an interface that looks broken in every language except the original.
Who is still on the project a year after launch
The local talent pool moves. Studios here often assemble a team of employees and independent specialists around a project, which is flexible and works well, but it means the person who understands your data model may not be reachable in eighteen months. This is fine if the work is documented and the accounts are yours. It is expensive if neither is true.
Protect against it in the contract rather than in conversation. Ask for the store accounts and the signing keys to sit with your company from day one. Ask for a written handover package: repository access, build instructions, environment configuration, third party service accounts and a list of every external library the product depends on. That list matters more than people expect, because an abandoned library is a future release blocked for reasons nobody budgeted for.
How pricing models behave on app work specifically
Fixed price works when the product is a known shape, for example a mobile app front end for a system that already exists and behaves predictably. It works badly when the product is new, because the supplier prices their uncertainty and you pay for it whether or not it materialises. Time and materials suits exploration but requires you to steer, and an unsteered arrangement drifts quietly rather than failing loudly.
A monthly team arrangement suits products that will keep changing after launch, which most of them do. Whichever you pick, agree a review point and a cap, and agree separately what maintenance costs once the build is finished. Every operating system release breaks something small, and a mobile app with no maintenance arrangement tends to sit untouched until it stops working on new phones.
Comparing Barcelona studios on evidence rather than on taste
Ask each shortlisted studio for a mobile app of theirs that is live today, then look at it yourself. Check how often it has been updated, read the recent reviews, and see whether anyone replies to them. Ask what they would drop from your requirement if the deadline were fixed, and ask what they think the riskiest part of your idea is. A team that cannot name a risk has not thought about your project yet.
Keep the shortlist to three, brief them with the same written document, and compare answers rather than presentations. If the product also needs a promotional site or design system alongside it, look at design studios working in the city rather than assuming one supplier covers both. To see the full set of firms building for phones before you narrow anything down, start from the mobile app development directory, and when your requirement is written, ask several verified suppliers for comparable offers at once.