What should a mobile app development company in Germany deliver?
A proper app partner delivers far more than screens: working apps in both stores, the backend they talk to, the accounts and code in your name, and a plan for the updates that every app needs each year. If a proposal only lists design and development, ask about the rest before you compare prices.
German buyers also need a few items that proposals from abroad often forget. The app needs an Impressum and a privacy policy that are reachable from inside the app, not just on the website. Tracking and crash tools need to wait for consent where the law asks for it. The store listings need your company’s verified trader details for the EU. And if the app sells to consumers, accessibility under the BFSG belongs in the brief.
A realistic deliverables list looks like this, and every mobile app development company in Germany or abroad should be able to show where each item sits in its quote.
- Clickable prototype or screen designs you sign off before coding
- Flutter or React Native source code in a Git repository your company owns
- Backend, database and admin panel, hosted in an EU region if the app stores personal data
- Store listings, screenshots, privacy labels and review submissions
- Consent handling, in-app Impressum and privacy policy links
- Test builds through TestFlight and Google Play testing tracks
- Handover document: accounts, keys, build steps and third-party services
What does the price difference between a German app agency and a team in India buy?
Mostly overheads and proximity, not better code. A German agency carries German salaries, offices, sales staff and account managers, and its day rates reflect that. A small remote team carries far less, so the same Flutter code can cost noticeably less to write.
What you give up for the lower price is real, and you should weigh it honestly. You lose in-person workshops and German as the working language: we work in English, and German copy for the app comes from you or a copywriter you choose. You lose a large bench of specialists who can be moved onto your project in a week. And your supplier sits outside the EU, which affects how your data protection officer documents any access we have to personal data.
What you keep is everything that ends up in the app itself: the framework, the architecture, the test process, the store release and the ownership. Quotes from agencies and freelancers vary widely, and we do not publish anyone else’s rates. The fairer comparison is to send the same written brief to a local mobile app development company and to us, then read both quotes line by line.
The gap is worth it when
Your team wants German workshops, the app is part of a large programme with many vendors, or procurement insists on a German contracting party.
A remote team makes sense when
The scope is clear, one or two people decide, you are comfortable with English video calls, and you want budget left for marketing and updates.
Flutter, React Native or native: which suits an iPhone-heavy German audience?
For most business apps, a cross-platform framework gives you both platforms at close to native quality, and Flutter is our default. Pure native (Swift for iOS, Kotlin for Android) is worth its extra cost only when the app lives on platform features such as advanced camera work, Bluetooth hardware, widgets or CarPlay.
Look at your own analytics before choosing. If your website traffic or customer base leans towards iPhone, the iOS version has to feel right first: native navigation gestures, system fonts, Face ID, Apple Pay where it fits, and fast start-up on older iPhones. Flutter draws its own interface and gives fine control over that look; React Native uses the platform’s native components and suits teams that already write React for the web.
A practical rule we use: pick Flutter when design consistency and performance on both platforms matter most; pick React Native when your company already has React developers who will maintain the app later; pick native when one platform dominates and the app depends on hardware features. Mixed builds are normal too. A Flutter app can call native Swift or Kotlin code for the one feature that needs it.
Who should own the App Store and Google Play accounts, and why do you need a D-U-N-S number?
Your company should own both developer accounts, enrolled as an organisation. A mobile app development company in Germany or anywhere else should be invited as a team member, never be the owner, because moving a published app between accounts later is slow and sometimes messy.
Both stores verify organisations through a D-U-N-S number, the nine-digit business identifier issued by Dun & Bradstreet. Apple’s enrolment page lists it as required for organisations other than government entities, along with a legal entity name, a work email on your company’s domain and a public website; the membership costs US$99 per year. Google Play charges a one-time US$25 registration fee and asks organisation accounts for a D-U-N-S number too, noting that getting one can take up to 30 days. Apply early.
Organisation accounts have a second advantage on Google Play. Google’s help centre says personal accounts created after 13 November 2023 must meet extra testing requirements before an app can go to production, which adds weeks to a first release. An organisation account avoids that detour and shows your company, not a private person, as the publisher.
- Order or look up your D-U-N-S number in week one
- Enrol with Apple and Google as an organisation, paid by your company
- Invite us with developer or admin roles, never as account holder
- Keep signing keys and certificates documented in your password manager
Trader details under the EU Digital Services Act: what your store listing shows
If you earn money from your app or use it for your business, you are almost certainly a trader under the Digital Services Act, and the stores display your contact details to EU users. Deciding your status is your responsibility, not the developer’s.
Apple’s App Store Connect documentation says traders must provide an address, phone number and email address, verify the phone and email, and upload documents proving the business name and address. For organisations, the address comes from the D-U-N-S record. Once verified, the contact details appear on the product page in all 27 EU countries. If you declare that you are not a trader, EU users are told that consumer protection rights do not apply to their contracts with you, which is not a message most German companies want on their listing.
Google Play shows the legal name, legal address, developer email and phone number for organisation accounts, taken from your verified payments profile. In practice that means your D-U-N-S record, your Google payments profile and your Impressum should all show the same company name and address. Mismatches are the most common reason store verification stalls, so we check all three before the first submission.
DSGVO for push notifications, analytics and crash reporting
Treat every SDK in the app as a data flow you have to justify. Analytics, advertising and many crash tools read or store identifiers on the phone, and under § 25 TDDDG storing or reading information on a user’s device needs consent unless it is strictly necessary for the service the user asked for. That rule covers apps, not just websites.
So the build starts the app with non-essential SDKs switched off. A first-run consent screen explains what each tool does in plain language, offers accept and reject with equal weight, and only then initialises analytics or marketing SDKs. The choice can be changed later in the settings screen. On iOS, Apple’s App Tracking Transparency prompt is a separate requirement for cross-app tracking; it does not replace your own consent screen.
Push notifications need their own thinking. The push token is needed to deliver messages the user asked for, but marketing pushes need opt-in, and your privacy policy must name the push provider. Crash reporting is useful from day one, so we configure it to collect as little as possible: no user names, no email addresses, and IP addresses dropped where the tool allows. Where a tool offers EU data storage, we select it.
- Inventory every SDK with purpose, data collected and storage region
- Initialise only strictly necessary SDKs before consent
- Separate transactional pushes from marketing pushes
- Mirror the SDK list in your privacy policy and store privacy labels
Your data protection officer or lawyer signs off the final set-up. We build it so their decisions can be applied without new releases where possible, for example by switching an SDK off remotely.
Store privacy labels and the Data safety form: keeping them honest
Both stores ask you to declare what data your app collects: Apple through the App Privacy section in App Store Connect, Google through the Data safety form in Play Console. These declarations have to match what the app and its SDKs actually do.
The trouble is that third-party SDKs collect data you never see in your own code. A maps SDK may log location; an advertising SDK may read device identifiers; a crash reporter may send device models and log lines. We keep the SDK inventory from the privacy work as the single source for the store forms, so the labels, the privacy policy and the consent screen say the same thing.
Whenever a release adds or removes an SDK, the labels change with it. We add that step to the release checklist, because an outdated label is easy to miss and store reviewers do reject apps over mismatches. Keeping the list short helps: every SDK we can replace with a few lines of our own code is one less entry to declare and one less data flow to explain to your users.
Does the BFSG apply to mobile apps?
Yes, for the services it covers. § 1 BFSG explicitly includes services offered on mobile devices, including mobile applications, and the covered services include e-commerce, consumer banking, passenger transport and e-books. The law applies to products and services placed on the market after 28 June 2025.
So a shopping app, a booking app with online payment or a banking-style app for consumers is likely in scope, while an internal app for your own technicians usually is not. The law exempts microenterprises that provide services; whether your company qualifies, and whether your app counts as an e-commerce service, is a question for your lawyer.
The technical work is the same regardless of the legal answer, and it is cheaper to build in than to retrofit. We test with VoiceOver on iPhone and TalkBack on Android, make every button and icon carry a readable label, support the system’s larger text sizes without clipped layouts, keep colour contrast readable in light and dark mode, and give touch targets enough size. Forms get proper error messages that screen readers announce. Flutter and React Native both expose the accessibility properties needed for this; the discipline is in using them on every screen. Our BFSG requirements page covers the website side and the accessibility statement.
How much does a mobile app development company in Germany charge?
Quotes vary widely, and the spread comes from scope and overheads more than from the framework. With BtechWaleTech a cross-platform app starts at US$600 and an app with its own backend and admin panel starts at US$900; German agencies price the same scope on their own day rates.
When you compare quotes, these are the items that actually move the number. Know them before you talk to anyone, so you can cut scope on purpose instead of by accident.
- User roles: a customer-only app is cheaper than customer, staff and admin views
- Backend: reusing an existing API or shop costs far less than building accounts, orders and documents from scratch
- Offline use: sync and conflict handling for technicians or drivers add real work
- Integrations: ERP, CRM, payment providers, calendars, IoT devices
- Design depth: custom animations and illustrations versus a clean system-style interface
- Compliance work: consent flows, accessibility testing, in-app legal pages
- Content and languages: German and English, or more locales
Running costs sit outside any build quote: the Apple membership, hosting, push and analytics tools, and maintenance. Budget for them from the start. The app cost guide for Germany walks through sample budgets by app type.
Milestone pricing in EUR: how payments follow the work
We quote in USD and you pay per milestone, in USD or EUR, by Wise, bank wire or PayPal. Each milestone ends with something you can open or install, so you never pay for progress you cannot see.
A typical split for a cross-platform app has four or five milestones: approved screen designs; a first test build with the core flow working; a feature-complete build on TestFlight and Google Play internal testing; and store release with handover. Larger apps add a milestone for the backend and admin panel. The exact split is agreed in your written quote, and anything the quote does not settle falls under our terms.
Currency is the one detail German finance teams ask about most. Paying in EUR through Wise usually means you see the converted amount before you send it, while a wire in USD leaves the conversion to your bank. Invoices come from India. How your accountant books them, including any reverse-charge VAT treatment, is their call; we do not advise on German tax.
Good milestone
“Build 2 installed on your phones via TestFlight and internal testing, login, booking and push working against the staging backend.”
Weak milestone
“50% of development complete.” Nobody can check it, so it invites disputes.
How to vet a mobile app development company before you sign
Ask for evidence you can install and questions they must answer in writing. Portfolio screenshots prove little; a live app in the store, from a publisher you can see, proves a lot more.
Send every candidate the same one-page brief and the same questions below. A good mobile app development company in Germany or abroad answers them specifically; vague answers on accounts, consent or updates tell you more than any pitch deck.
- Which live apps did you build, and under whose store account are they published?
- Flutter, React Native or native for our app, and why?
- Which SDKs will you add, and which of them need consent?
- How do we test builds before release, and on which devices?
- Who owns the repository, the store accounts and the signing keys?
- What happens when iOS or Android releases a new major version?
- How are milestones defined, and what exactly do we receive at each one?
- Who covers the project if the lead developer is unavailable?
Also check references for the unglamorous part: how the team handled a rejected store review or an urgent crash after release. Those stories show how a partner behaves under pressure.
Working with an app team in India from Germany: the first two weeks
India is 3.5 hours ahead of German summer time and 4.5 hours ahead in winter. A 9:30 stand-up in Munich lands in our early afternoon, so your whole morning and early afternoon overlap with our working day.
Days one to three: a video call to walk through the brief, followed by a written scope summary you correct. You start the D-U-N-S and store enrolment if they are not already done, and give us access to any existing API, design files or shop. Days four to seven: wireframes of the main flows, a decision on Flutter or React Native in writing, and the list of SDKs with their privacy impact for your data protection officer.
Week two: first high-fidelity screens, the repository created in your GitHub or GitLab organisation, the CI pipeline set up, and a first empty test build installed on your team’s phones, which proves the accounts and signing work long before anything important depends on them. From then on, updates go out on WhatsApp during your working hours and each finished feature arrives as a new test build.
No visits and no local office: everything runs over video calls, shared documents and test builds. Contracts and invoices are issued from India, and your quote spells out scope, milestones and ownership.
Backend, admin panel and EU hosting for German apps
If the app stores personal data, host its backend in an EU region and keep a record of every processor involved. For most German clients that means a database and API in AWS Frankfurt or another EU region, set up in your own cloud account.
Not every app needs a heavy backend. A content or catalogue app can read from your existing CMS or shop API. A booking app may sit on top of the booking tool you already pay for. Apps with accounts, orders, documents or staff workflows usually need their own API, a database with backups, role-based access and an admin panel your team uses in the browser; that is where the US$900 starting point applies.
Security basics are part of the build, not an extra: encrypted connections, hashed passwords or a proven identity provider, least-privilege roles for staff, audit logs for sensitive actions and secrets kept out of the app bundle. Our access to production data is limited to what the work needs, and your data protection officer decides how that access is documented, since our team works from India.
App Store search, your website and AI answers
People find apps through store search, your website and, more and more, AI assistants that recommend tools. Each channel needs clear, factual text about what the app does and who it is for.
In the stores, the app name, subtitle, keyword field on iOS and the short description on Google Play carry the most weight, and screenshots decide whether people install. German listings need German text, which you or your copywriter provide; we set up the listings, localisations and screenshot sizes. On the web, a small landing site with store badges, a clear feature list, an FAQ, the privacy policy and the Impressum gives Google and AI engines something reliable to quote.
We add structured data for the app and the organisation on that site, connect Google Search Console, and keep facts consistent between the store listing and the website. Nobody can guarantee store rankings, search rankings or AI citations, and we will not pretend otherwise. Ongoing SEO support for the website starts at US$150/mo.
Red flags when comparing app development companies in Germany and abroad
Most failed app projects show warning signs in the proposal, long before the first line of code. These are the ones we see most often when companies ask us to take over an app another supplier started.
- The app will be published under the supplier’s developer account
- No written list of SDKs, or analytics that start before any consent
- Source code handed over only at the end, or only as a zip file
- Milestones described as percentages instead of installable builds
- No plan or price for yearly iOS and Android updates
- A proprietary framework or builder that only this supplier can maintain
- Promises of top store rankings or download numbers
- Accessibility dismissed as ‘only for public sector apps’
One flag alone may have an explanation. Three or more, and it is usually cheaper to keep looking before you sign.
Worked example: a Stuttgart machine builder plans a service app
This scenario is hypothetical and only illustrates how a quote comes together; it is not a client project.
Say a mid-sized machine builder near Stuttgart wants an app for its customers’ maintenance staff. Users should scan a QR code on a machine, see its manuals and spare-parts list, report a fault with photos, and follow the service ticket. The company already runs an ERP and a ticket system, and most users work on the shop floor with patchy signal.
We would propose Flutter for one codebase on the iPhones and Android phones the customers already carry, with offline caching of manuals and a queue for fault reports sent when the signal returns. The quote would start from the custom backend and app line at US$900, with separate lines for the ERP and ticket-system connections, QR handling, offline sync, German and English interfaces with text supplied by the client, and accessibility testing. Because the app serves business customers rather than consumers, the BFSG may not apply, and the client’s lawyer would confirm that.
The stores would publish the app under the machine builder’s own organisation accounts, with trader details matching its Impressum. Hosting would sit in the client’s AWS account in Frankfurt. A realistic timeline would be ten to twelve weeks, depending mostly on how quickly the ERP interface documentation arrives.
After launch: OS updates, store policy changes and maintenance
An app is never finished. Apple and Google release major operating system versions every year, change store policies and raise the minimum SDK levels they accept, so budget for regular updates from the start.
For two months after release, maintenance is free: crash fixes, small changes, dependency updates and help with store review questions. After that, maintenance starts at US$120/mo, and it covers testing against new iOS and Android versions, updating Flutter or React Native and their plugins, renewing certificates and keeping privacy labels current. You can stop it whenever you want, and because the code, accounts and documentation are yours, any other developer can take over.
We also watch crash reports and store reviews in the first weeks after each release, because that is when real devices show problems that test phones did not. Feature work after launch is quoted separately, like the original build, so you always know what a change costs before it starts.