Our app projects start at €1,500. That starting point applies to a focused, functional app: a few screens, a clear purpose, and a connection to a backend or existing API. More complex apps with many screens, realtime data or heavy integrations cost more, in line with the extra development time.
Native, or one codebase for both platforms
The biggest price lever is not the number of screens, but the choice between native development (separately for iOS and Android) and cross-platform with, for example, React Native. Cross-platform means one codebase for both platforms, which brings build time and therefore price down considerably without compromising on feel or speed. We only recommend native when an app truly needs functionality that requires it.
What is often forgotten in a price estimate
Publishing in the App Store and Play Store, including store listings, screenshots and the review submission to Apple and Google, is a standard part of a project. The same goes for push notifications and basic analytics: functionality that makes an app genuinely useful after launch.
An MVP versus a full app
An MVP (minimum viable product) contains only the core functionality needed to test your idea with real users: no extensive settings, no edge cases, no polish that only matters at scale. That is deliberate: an MVP is meant to learn whether your assumption holds, not to be complete straight away. As a result, an MVP usually sits at the lower end of our range.
A full app with account management, payments, offline support and extensive edge-case handling costs considerably more, simply because each of those parts needs its own design, build and testing. We advise most first-time founders to start with an MVP: live sooner, less risk, and the next phase can be based on real usage data rather than assumptions.
The role of backend and APIs in the price
An app that only works locally on the device (like a calculator or an offline notes app) is relatively cheap, because no server, database or API is involved. As soon as an app needs to store data, let users log in, or sync between devices, a backend is needed: a server that processes and stores data. Building and securing that backend is often at least as much work as the app itself.
Does the app need to connect to an existing system, such as a CRM, accounting package or inventory system? Then the price depends heavily on how well documented and accessible that system’s API is. A modern, well-documented API takes days to integrate; an outdated or poorly documented system can extend the build considerably.
Maintenance after launch
An app is never "done" after launch, even if no new features are added. Apple and Google regularly release new OS versions, and an app that is not tested and updated for them risks crashes or even removal from the store. Expect ongoing maintenance, similar to websites: at TechGents this falls under the same maintenance plans, depending on how actively the app is used.
Also budget for the developer accounts themselves: Apple charges an annual fee for the App Store, Google a one-off fee for the Play Store. Small compared to the build costs, but a recurring item that is easily forgotten in a first budget estimate.
How to estimate your own budget
Before requesting a quote it helps to be clear on three things: the core problem the app should solve (in one sentence), which two or three features are really needed for that, and which features are "nice to have" but not essential for the first version. Agencies that go through this distinction with you before writing a quote usually give you a more realistic picture than agencies that immediately present a complete feature list.
Design: why it is often underestimated
An app that looks "just okay" gets deleted faster than one that feels familiar and well thought out, however good the technology underneath. Users unconsciously compare your app with the apps they use every day, even if those come from completely different companies with far bigger budgets. That does not mean you need the same budget, but it does mean UX design (how users navigate, where buttons are, how errors are shown) should not be an afterthought.
That is why we always reserve a separate part of every app project for design and a clickable prototype, before any code is written. It prevents building on an idea that turns out awkward to use, and changing a design is far cheaper than rewriting working code.
Testing on real devices
An app that works perfectly in the developer’s simulator can still cause problems on an older device or a different screen size. Thorough testing on a range of real devices, screen sizes and both operating systems is not a luxury but a standard part of a careful project. Agencies that skip it to deliver faster move the problem to after launch, when a bug goes live and users run into it first.
What a good technical choice saves you later
Choosing a modern, well-maintained tech stack (for example React Native with a well-structured backend) really pays off at the first big extension: adding features to a clean codebase takes a fraction of the time it takes to cram the same features into an outdated or messy app. So when you request a quote, ask not only about the price of the first version, but also how maintainable and extensible the chosen technology is for what you want to build in the long run.
Freelancer, agency or an in-house developer
For a first app a freelancer is sometimes the cheapest option, but it carries risk: in case of illness, other work or departure, there is nobody to take over without first working through someone else’s code. An agency with several developers costs more per hour but offers continuity: if someone drops out, a colleague can take over because the way of working and documenting is shared. Hiring your own developer only pays off at a scale where you need development capacity all year round, which is not yet the case for most new app ideas.
For most small businesses a small, fixed team at an agency is the practical middle ground: the directness of a freelancer, with the continuity of several people who know the project.
The first months after launch
The period right after launch is often busier than expected: users find ways to use the app that were not fully anticipated, small bugs only surface with real use, and feedback from the first users often prompts small changes straight away. Deliberately reserve room for this in your planning and budget, instead of assuming the project is finished the moment it goes live.