Before asking for quotes, be clear about what you want
You can't compare companies fairly if each one has quoted a different app. Before the first meeting, it helps to be clear about:
- What you want to achieve with the app and how you will know it works.
- Who will use it: customers, professionals or your own team.
- What is essential for the first version and what can wait.
- Which systems it has to talk to: an ERP, a CRM, corporate sign-in.
- Who decides in your company and who will be available to review progress.
That way every company quotes the same thing and the differences between proposals mean something. The cost guide has a full list of what to have ready.
Small studio, large agency, freelancer or in-house team
No option is best for everyone. What changes is who does the work and how much it involves you:
- A small studio: you talk to the people who design and build the app. It fits when you want direct contact and continuity, and a small team can handle the app.
- A large agency: has more people and can handle several fronts at once (brand, campaigns, the app). It fits very large projects or when the app is one piece of something bigger. Ask who will build your app and whether the team is in-house or subcontracted.
- A freelancer: can be the cheapest option for something well defined. Check what happens if they aren't available and who takes care of the backend, the design and publishing.
- Your own team: makes sense if the app is at the heart of your business and you'll keep evolving it. Allow time for hiring and remember you need several profiles (design, iOS and Android, backend).
Start.cat is a small, senior studio: the same team runs the project from the first sketch to maintenance.
What to ask in the first meeting
- Who will build the app? The actual people, whether the team is in-house and whether any part is subcontracted.
- With what technology? Native, with one codebase per platform, or cross-platform, such as React Native or Flutter, with a single codebase for iOS and Android. Both are valid; what matters is that they explain why they chose it for your app. We use React Native and drop down to native code when needed.
- Who owns the code? The contract should state that the code and the design are yours when the project ends. With us, the code belongs to the client.
- Whose name is the app published under? Usually the Apple and Google developer accounts are yours, in your company's name: that way the app is yours even if you change provider one day.
- What happens after launch? Who keeps the app up to date with each iOS and Android release, what it costs and what it includes.
- Which apps have they published? Ask to see them in the stores, not just in screenshots, and whether they are still updated.
What a healthy process looks like
What should happen between the first call and the published app:
- A conversation to understand the project: goals, users and constraints. In our case, a 30-minute call.
- A written proposal with scope, schedule and price, with no small print.
- A prototype of the key screens before coding. Changing a screen in the prototype takes minutes; in the finished app, days.
- Development in short iterations, with test builds you can install on your phone from the start. If you don't see the app until the end, that's a warning sign.
- Publishing on the App Store and Google Play, with the store listings, the privacy forms and the Apple and Google reviews.
- Maintenance, so the app keeps working with new iOS and Android versions.
As a guide, an app with the essentials takes 2 to 3 months and one with a custom backend, 3 to 5 months; those connected to corporate systems take longer. The details are in the cost guide.
Data, GDPR and where it is hosted
Almost every app handles personal data: a sign-up, an email, a location. Ask:
- Where the servers will be. With providers in the European Union, data protection is simpler. We host backends mainly on Clouding.io, a Barcelona provider with its servers in Spain.
- Whether you will sign a data processing agreement. Whoever builds and hosts the app processes data on behalf of your company, and the GDPR requires that agreement.
- What data the app collects and why. Collecting only what is needed is safer and easier to justify.
If the app handles health data, the requirements go up: we explain them in the clinical study app guide.
Warning signs in a quote
- A figure with no breakdown. If you don't know what it includes, you can't compare it with another.
- The backend, admin panel, testing or publishing is missing. If the cheapest quote doesn't include it, you'll pay for it later.
- Nothing about maintenance. An app without maintenance stops working properly within a year or two.
- It doesn't say who owns the code or whose name the app is published under.
- A very short deadline with no prototype or test builds. Fast without reviews usually ends in expensive changes at the end.
- A fixed price for an open scope. If the scope is unclear, the fixed price will end in arguments or cuts.
Examples of published apps
To see what a real project looks like, here are some apps we have built:
- Club RUBI: loyalty app for construction professionals, in the stores since 2018.
- Compo Expert: fertiliser catalogue with agronomy tools, synced with the company's systems.
- Cohorte ARCA: monthly follow-up of a cohort of children and teenagers with asthma, for the Hospital del Mar Research Institute, on the App Store since 2017.
- Your Decision: shared decision-making app and portal for patients with localised prostate cancer.
- D2M: protein portion calculator for the Hôpital Robert-Debré in Paris.
If you come from health or research, see also apps for health and research.