What an App Really Costs — and Why the Wrong Technology Choice Is More Expensive Than Development Itself

A mid-sized retailer invested €180,000 in a native iOS app. Eighteen months later, 60% of their customers — Android users — were still waiting for a version that worked on their devices. By the time the Android app finally launched, the iOS version already needed a major update. Total cost: over €300,000. A cross-platform solution could have served both platforms simultaneously — for around €120,000.

This isn't an isolated case. It's the pattern we at Golle IT have observed repeatedly across more than 500 projects since 2010: the most expensive decision in app development isn't the development itself — it's choosing the wrong technology. And those costs compound over years.

This article gives you the cost-benefit analysis you need before commissioning your next app project. Not a sales brochure, but an honest decision framework with real numbers, hidden cost traps, and a clear recommendation for when each approach makes sense.

The Three Development Approaches — Without the Jargon

Before we talk about costs, three terms need to be clearly defined. Not technically, but from a business perspective.

Native Development

Two separate apps, two separate codebases: one for iOS (Swift), one for Android (Kotlin). Maximum platform integration, maximum effort. Every feature is built twice, tested twice, maintained twice. This makes sense if you need hardware-level features — such as AR applications that push camera performance to its absolute limits. For the vast majority of business applications, it's simply over-engineering.

Cross-Platform (Flutter, React Native)

One codebase, two platforms. Flutter (by Google) and React Native (by Meta) are the dominant frameworks. The app is written once and runs on both iOS and Android — with Flutter, even on desktop and web. The performance gap compared to native apps has closed dramatically since 2022. The cost advantage has not.

Progressive Web App (PWA)

A website that feels like an app. No app store, no installation required. Works for simple use cases — information portals, basic booking systems. Runs into limitations with offline functionality, push notifications on iOS, and hardware-level access. For most businesses planning a "real" app, it's more of an interim step than a solution.

The key insight: Choosing between these approaches isn't a technology decision. It's a business decision — about budget, team structure, maintainability, and speed to market.

The Real Cost Matrix: What You Actually Need to Budget For

Most cost guides show you a table of development costs and stop there. That's like comparing only the sticker price when buying a car and ignoring insurance, maintenance, and fuel.

Initial Development Costs by Complexity

The following figures are based on industry estimates from multiple independent sources. Independent benchmark data for the DACH market is limited in availability — but the ranges are consistent enough across sources to serve as a reliable reference point. Note: developer rates in the DACH region are above the global average, so your projects will likely land toward the upper end of these ranges.

Most SME projects in the DACH region fall into the medium complexity tier. Industry estimates suggest that cross-platform development with Flutter or React Native saves 30–50% of initial build costs compared to two separate native apps. Put another way: dual-native development costs 60–70% more than the cross-platform approach.

The 3-Year Total Cost of Ownership — The Number That Actually Matters

This is where it gets interesting. Initial build costs typically represent only 40–60% of what a company spends on its app in the first three years. The rest is distributed across maintenance, updates, OS compatibility fixes, and feature enhancements.

Most practitioners estimate annual maintenance costs at 15–20% of initial build costs. This isn't a verified study — it's a well-established rule of thumb from real-world experience. But it fundamentally changes the calculation:

The takeaway: the savings from cross-platform grow with every passing year. The maintenance cost advantage doesn't just offset the initial difference — it amplifies it. With a dual-native solution, you're maintaining two codebases, responding to two sets of OS updates, and running two test pipelines.

The Hidden Costs That Never Appear in Agency Brochures

GDPR Compliance: Every app that processes user data — which is nearly all of them — requires consent management, data minimization, and potentially EU data residency. This isn't a checkbox on a list; it's real development effort. Budget an additional €5,000–€15,000 depending on data complexity.

European Accessibility Act (EAA): Since June 2025, digital products sold to consumers in the EU must meet accessibility standards. Companies that don't plan for this from the start pay multiples for retroactive adjustments. Retrofitting accessibility is technically complex and expensive — building it in from day one costs a fraction of that.

App Store Fees: Apple's 15–30% commission on in-app purchases and subscriptions is not a footnote — it affects your entire business model. More on this in our article on in-app purchases.

OS Update Compatibility: Every year, Apple and Google release new operating system versions. Every year, apps need to be updated accordingly. With two native codebases, that effort doubles.

Developer Dependency: And this is where things get strategically significant.

Why the Technology Decision Is Really a Staffing Decision

This point is ignored in most cost comparisons — yet for SMEs in the DACH region, it may be the most important one.

As Chop Dawg aptly noted in their 2026 analysis: "The real tradeoffs in 2026 go beyond performance benchmarks and touch on team structure, maintenance burden, and platform-specific UX expectations."

Let's translate that into the reality of a mid-sized business: you have a native iOS app. Your only iOS developer resigns. Now you're choosing between expensive freelancer day rates (€800–€1,200 per day for experienced iOS developers in the DACH region) or a partial rebuild. Both are painful, both are expensive, and both were avoidable.

A cross-platform Flutter app reduces this key-person risk. A single Flutter developer can maintain both platforms. The talent pool is larger, and dependency on individual team members is lower. For a company with 50–500 employees, this isn't a theoretical argument — it's practical risk management.

Ask yourself: Who in your organization will maintain the app after launch? If the answer is "no one" or "the agency will handle it," you have a problem that no technology choice can solve. A €200,000 app without an internal owner isn't an asset — it's a liability.

The Decision Framework: 6 Questions Before a Single Line of Code

Here is the framework we use at Golle IT in client conversations before any project begins. No technology debate — instead, six business questions that lead to the right answer.

Question 1: Who Are Your Users — and Which Platform Do They Use?

Check your web analytics. If more than 40% of your target audience uses Android — and in Germany, Android's market share sits at around 65–70% — a pure iOS solution is a strategic mistake from day one. Cross-platform is the default here, not the exception.

→ More than 40% Android users? Cross-platform.

Question 2: What Does Your 3-Year Budget Look Like — Not Just Your Build Budget?

If your total budget over three years is €150,000, you cannot afford dual-native development — even if the initial build costs might still fit. Maintenance will consume the rest. Always calculate with TCO.

→ Budget under €200,000 for 3 years? Cross-platform.

Question 3: Do You Need Hardware-Level Performance or Platform-Specific Features?

AR applications leveraging the latest camera APIs. Bluetooth Low Energy integration with industrial sensors. High-performance 3D graphics. These are the cases where native development delivers a genuine advantage. For an ordering app, a CRM front end, or a customer portal? You don't need it.

→ No specialized hardware integration? Cross-platform.

Question 4: Do You Have an Internal Technical Owner After Launch?

Without someone who can set update priorities, evaluate user feedback, and manage the agency relationship, every app becomes a money pit. This isn't a technology question — but it influences the technology choice. A cross-platform app is easier to hand over and maintain than two native codebases.

→ No internal tech team? Cross-platform, with a maintenance contract.

Question 5: What Are Your Compliance Requirements?

GDPR is mandatory for virtually every app. EAA compliance since June 2025 for B2C apps. Industry-specific regulation (financial services, healthcare) adds further requirements. Compliance obligations increase scope — and with two native codebases, they must be implemented twice and audited twice.

→ High compliance requirements? Cross-platform (implement once, compliant everywhere).

Question 6: MVP or Production System?

If you want to test a market, build an MVP. Fast, lean, and built to generate learnings. If you're building a system that needs to generate revenue from day one, plan accordingly. The most dangerous trap: starting with a "simple" MVP and then bolting on features one by one without an architecture designed for it. Companies that take this approach often spend more than those who plan for medium complexity from the start.

→ Market test? Lean MVP, cross-platform. Production system? Plan properly — cross-platform with scalable architecture.

The Short Version

For the vast majority of SMEs in the DACH region, the recommendation is clear: cross-platform with Flutter. The cases where native development is genuinely the better choice — specialized hardware, high-performance graphics, platform-specific AR/VR — are rare in a typical mid-market context. The performance gap between Flutter and native has closed dramatically. The cost gap has not.

Three Real-World Project Examples

The following examples are anonymized composites based on real project experience. The figures are representative, not exact.

Example 1: B2B Ordering App for a Wholesale Distributor

Context: A wholesale distributor with 200 employees wanted to move its field sales team from paper order forms to a mobile solution. 80 field reps, mixed device fleet (iOS and Android).

Decision: Flutter, medium complexity. Offline capability, integration with existing ERP via REST API, barcode scanner.

Costs: €85,000 build, €14,000/year maintenance. 3-year TCO: €127,000.

Outcome: Order error rate reduced by 40%, average order time cut from 12 minutes to 3 minutes. ROI achieved within 14 months.

What would have happened with native? Estimated build costs: €140,000. 3-year TCO: over €200,000. Same functionality, double the price.

Example 2: Customer App for a Regional Insurance Provider

Context: An insurer with 15,000 customers wanted to digitize claims submissions and offer a self-service area. Strict compliance requirements (GDPR, financial regulatory oversight).

Decision: Flutter, high complexity. Encrypted document upload, biometric authentication, push notifications, EAA-compliant accessibility.

Costs: €165,000 build, €28,000/year maintenance. 3-year TCO: €249,000.

Outcome: 35% of claims submissions processed through the app within 6 months. Estimated 20% reduction in case handler workload.

Key insight: EAA compliance was planned from the start and cost approximately €12,000 additional in the build phase. A retroactive retrofit was estimated by the development team to cost €30,000–€40,000.

Example 3: MVP for a Fitness Startup

Context: A founding team wanted to test a fitness app with personalized training plans. Budget: €40,000. Time pressure: 8 weeks to market test.

Decision: Flutter, simple MVP. User registration, training plan display, basic tracking, push notifications.

Costs: €32,000 build, €5,000/year maintenance.

Outcome: 2,000 downloads in the first 3 months — enough validation to secure Series A funding. The app was subsequently expanded to medium complexity, because the Flutter architecture had been built to scale from the start.

What could have gone wrong? If the MVP had been built natively for iOS only, 65% of the target audience (young, fitness-oriented users with an above-average Android share) would have had no access. The market test would have been inconclusive.

The AI Factor: How Artificial Intelligence Is Changing the Cost Structure

We wouldn't be an honest software agency with an AI focus if we ignored this point.

Tools like GitHub Copilot, Cursor, and AI-assisted testing are measurably compressing development timelines. Some development teams report 20–40% faster delivery on standard features. Reliable, independent benchmark data on this is still limited — the pricing implications are only now working their way through the market.

What we observe: AI tooling benefits cross-platform development more than native. The tooling ecosystems for Flutter/Dart and React Native/JavaScript are more mature in AI-assisted development environments. This means the cost advantage of cross-platform is likely to grow further with AI, not shrink.

The strategic implication: AI doesn't change the decision framework. But the savings from making the right technology choice materialize faster. Companies that make the wrong decision today won't wait three years to feel the consequences — they'll notice within twelve months.

What Most Cost Comparisons Get Wrong

Most articles treat the technology decision as the primary decision. It isn't.

The primary decision is: What problem does this app solve — and for whom? Technology follows from that. An article that starts with "here's what Flutter costs" is solving the wrong problem. A company that starts with "our customers need X, and Y is the most efficient way to deliver it" makes better decisions.

The second blind spot: organizational readiness. Does your company have someone who can own the app after launch? Someone who sets priorities, evaluates user feedback, and steers the product roadmap? If not, that's not a technology problem — but it makes every technology decision riskier.

And the third: scope creep. The complexity tiers in our cost matrix are not fixed categories. A company that starts with a "simple" MVP and then adds feature after feature often spends more than one that planned for medium complexity from the beginning. Every retroactive extension of an architecture not designed for it costs more than the same scope in the initial design.

Your Next Step

The companies that achieve the best results in app development aren't the ones with the largest budgets. They're the ones that asked the right questions before writing a single line of code.

The decision framework in this article — the six questions, the cost matrix, the 3-year TCO calculation — is the tool we use at Golle IT to kick off every client project. Use it before your first agency conversation.

Planning an app and want clarity on technology, costs, and timeline before you start? Talk to us — in a no-obligation initial consultation, we'll assess your project and give you an honest evaluation of which approach is right for your situation. No sales pitch, just a well-founded assessment.

Or start with our guide for SME decision-makers on app development — it covers the complete process from idea to launch.

Building the wrong app is almost always more expensive than building no app at all. Building the right app at the right time with the right technology is one of the best investments a mid-sized business can make today.