App development is one of the topics we receive the most enquiries about, and the first question is almost always the same: what does an app cost? Before that can be answered seriously, three other questions must be settled. Who uses the application, on which devices, and what should it do? This guide describes how we approach these questions and where projects typically go wrong.
The form factor decides budget and operation
There are three basic form factors. A web app runs in the browser and adapts to any screen. A progressive web app, or PWA, can additionally be installed on the home screen, works offline with a service worker and can send push notifications, on iPhone since iOS 16.4. A store app is developed natively or cross-platform for iOS and Android and distributed through the stores. For most business applications, such as portals, data capture, booking and internal tools, a PWA is enough. A store app is needed for deep access to device features such as Bluetooth, NFC or persistent background processes, for in-app purchases, or when the audience searches only in the store.
Why we don’t build native apps
We build web apps and PWAs on the same stack that runs our own product portfolio. We do not build native apps in Swift or Kotlin, and we do not claim to. If a project needs a store app, we take on requirements, concept, partner selection and project leadership. The benefit for you: our recommendation for or against a store app is not shaped by our own utilisation. Our app form factor check gives a quick first impression.
A concept before code
Most app projects that cost more than planned fail on unclear requirements, not on technology. A short concept clarifies user groups, core features, the first scope, data model, interfaces and data protection, and includes a clickable mock-up of the key screens. With this concept, quotes become comparable, including those of other providers. We offer it as a separate app concept, with no obligation to build with us.
Data protection and accessibility belong in week one
Almost every business app processes personal data. Storage location, retention periods, access rights and contracts with providers are part of the concept, not of acceptance. For PWAs there is the added question of which data may be cached on the device. For apps with consumer customers in the EU, the European Accessibility Act and its implementations such as Germany’s BFSG have required accessibility since June 2025. Retrofitted, both cost many times more.
From prototype to production
More and more enquiries start with a prototype built in an AI app builder or no-code tool. That is a good start because the idea becomes tangible. For operation, such prototypes usually lack proper permissions, tests and a robust data model. We treat the prototype as a specification and rebuild the application on a stack you can run long term.
The main cost drivers
No serious figure can be given without a concept, but the drivers are known: number of user roles, number and quality of interfaces to existing systems, offline requirements, form factor, accessibility, multilingual content and operation after launch. Our page on the cost of app development describes them in detail.
Common mistakes
- The form factor is never consciously decided but follows from the first quote.
- Store accounts are created in the agency’s name and are hard to transfer later.
- Operation after launch is not agreed, and the app becomes outdated with the next operating system.
- Features are invented during development, and each becomes a change request.
- Real users see the app only shortly before launch.
Questions for every provider
Which form factor do you recommend and why? Who owns code, access and store accounts? Where is the data? How are changes and acceptance handled? Who handles updates and security fixes after launch? Our checklist for choosing an app agency lists these questions with criteria. If you have a concrete project, an initial conversation is the cheapest next step.