Mobile App Development
Mobile apps designed
for real business operations
Flutter, React Native, and native iOS/Android — scoped honestly, tested properly, and submitted to the stores without drama. Built for the operations team that will actually use them.
What a real mobile project looks like
Most of our mobile work is not a consumer app chasing downloads. It is an app a field team uses every day, a companion to a web platform, or a customer-facing app that replaces a clunky web checkout. The bar is simple: the people who use it should prefer the app to the spreadsheet, the phone call, or the printed form it replaces. If it is not better than those, it should not exist.
That framing changes how we build. We spend real time on offline behaviour, because a driver without signal is a very common real-world user. We treat authentication, session timeouts, and biometric login as first-class UX. We design list screens to survive a thousand records without the user waiting. And we invest in the feedback loop — crash reporting, analytics, and an in-app way to report issues — from week one.
We do not take on casino-style apps, clones of existing viral apps, or projects whose business model starts with "we will also sell the user data." We are picky about this for a reason: our reputation is worth more than one contract.
Native vs cross-platform: how we actually decide
Nearly every mobile conversation starts with "should we go native, Flutter, or React Native?" There is no universal answer — the right call depends on who is going to maintain the app in two years, what hardware features you need, and how different iOS and Android experiences need to be.
In practice we default to Flutter when the UI needs to feel tightly controlled and the team does not already have strong Swift or Kotlin engineers. Flutter gives us one codebase, a strong layout engine, and excellent performance for screen-heavy business apps. We reach for React Native when there is already a Next.js or React web product the team maintains and we want shared hooks, validation, and data-model code between web and mobile. We go fully native when the core of the app is deep platform integration — CoreML on iOS, advanced background location on Android, or anything that needs tight battery control.
What we almost never recommend is writing two fully separate native apps for an SME budget. It doubles the cost, doubles the bug surface, and rarely buys anything the user can feel.
What a mobile engagement really includes
A mobile build is never just "the app." A good mobile engagement always ships with: a backend or BFF (backend-for-frontend) service that the app talks to, an API contract you can read in one sitting, a designed and tested authentication flow, a staging environment mirrored from production, crash reporting (Sentry or Firebase Crashlytics), lightweight analytics, release-lane configuration for TestFlight and Play Internal Testing, and a documented build pipeline.
We also handle the annoying bits nobody talks about in a sales meeting: App Store Connect and Google Play Console setup, app-signing certificates, privacy manifests, data-safety declarations, screenshot generation at every required size, and the first store submission (including rejections — we almost always hit at least one). We hand this over as a checklist so your team knows what maintenance requires.
Maintenance after launch is not optional. iOS and Android each ship breaking changes on an annual cycle, and stores routinely require apps to rebuild against the latest SDK to keep listings alive. We include a maintenance plan in the original proposal so you are not surprised in month nine.
Security, privacy, and the things that get SMEs into trouble
Mobile apps ship on untrusted devices, in unpredictable networks, often carrying the most sensitive data in the entire product. We treat that seriously: encrypted-at-rest local databases for anything personal, short-lived access tokens with refresh rotation, certificate pinning for high-value environments, biometric-gated reauth for payments or admin actions, and a clean policy for what happens when a device is lost.
For EU clients we take GDPR seriously from the first sprint: we minimise the data the app collects, write a privacy policy in plain language alongside the legal one, and make sure "delete my account" actually deletes the data the company has about the user — not just hides it. For clients processing payments we steer firmly towards PCI-scope-minimising flows using Stripe, Adyen, or an equivalent provider rather than storing card data anywhere we control.
We document all of this. If a regulator, auditor, or acquirer ever asks, you already have the answers.
Timelines and budget tiers
We usually describe mobile engagements in four tiers. A focused single-purpose app for internal use — one role, simple CRUD, a handful of integrations — typically takes 8–12 weeks. A real consumer or customer-facing product with onboarding, payments, and push notifications runs 14–20 weeks. A multi-role platform app with offline-first workflows and admin tools is a 6-month program split into phases. Anything bigger than that — multi-country, multi-language, integrations with legacy systems — is a year of work and needs to be scoped in iterations with explicit decision points.
Budget-wise, we are honest that SME mobile apps rarely make sense below a mid-five-figure EUR range in 2026. If your budget is smaller, we will often recommend a mobile-first responsive web app first and a native app once the business has validated the workflow.
Mobile App FAQ
Questions we hear
on every mobile sales call
Can we ship only Android first and add iOS later?
Yes, and sometimes we recommend it — especially for apps where 90% of your users are on Android or where the distribution channel is enterprise / MDM. If we build in Flutter or React Native the second platform is incremental rather than a whole second project. With pure native, the iOS build is effectively a separate effort and we will price it that way.
Do we get the App Store / Play Store listings in our name?
Yes. Developer accounts are created under your legal entity from the start — not ours. We are invited in as team members with the right permissions. Your Apple and Google accounts, tax and banking details, and app ownership records all stay with you. We can help you open the accounts if your team has not done this before.
What happens when Apple or Google reject the app?
We assume at least one rejection on a first submission — it is normal. We handle the back-and-forth with the reviewer, make the required changes, and resubmit. The cost of routine review responses is already included in a first launch. What we scope separately is a full re-architecture driven by a policy change (for example, major data-collection rule updates), because that is genuine product work.
Can the app work offline?
Often yes, but "offline" is a spectrum. We can build read-only caches, queue-and-replay writes, conflict resolution with timestamp strategies, or full local-first databases like SQLite or Isar. Each costs more than the last. We start by asking what your users actually need to do without signal and scope the offline story to match — rather than promising "100% offline" and then shipping a UX that breaks the first time two devices disagree.
Who handles push notifications, deep links, and analytics?
We do, as part of the default scope. Push is usually Firebase Cloud Messaging (or APNs direct if the client has strict data-residency needs). Deep links use Universal Links / App Links so they survive app updates. Analytics ships with a small, privacy-friendly event model by default; we will integrate a heavier stack like Mixpanel or Amplitude on request.
How much does it cost to keep the app alive each year?
Budget at least one focused maintenance release per year to keep the app compatible with the latest iOS and Android SDKs, plus any store-policy driven changes. In practice a typical SME business app needs 40–100 engineer-hours per year just to stay green. That number climbs if you add features. We put this on the proposal up front so it is never a surprise.
Book a mobile consult
Scope your mobile app
with an engineer, not a sales rep
Tell us what the app needs to do, who uses it, and what "done" looks like. We will come back with a realistic stack choice, a timeline, and a number you can actually plan around.