A mobile app that actually gets used — not one that gathers dust in the store.
Mobile apps and progressive web apps from Germany, built as an honest channel for a real workflow — a customer app, a field-service app, booking and self-service, an internal mobile workflow, or a companion app to a product. With a clear call between PWA and React Native, a tight MVP scope, backend, auth, push, offline, and a real store path. Founder-led, from Krefeld.
- PWA · React Native · Expo · TypeScript · Node / .NET backend
- App Store / Play Store release, review rounds included
- Based in Krefeld · Germany & EU · GDPR-aware
When a mobile app is a real investment — and when it isn’t.
An app icon on a home screen is not a marketing trophy. It earns its place when there is a recurring workflow that runs distinctly better on mobile than in a browser tab: field-service orders, bookings and appointments, loyalty, on-site documentation, live status for customers, or a companion to a physical product. If that workflow is unclear, a native app is almost always the wrong answer — and a solid web app or progressive web app (PWA) is the better first step. That is why p24.co plans mobile projects from the back: the workflow first, then the “PWA or React Native” question, then the MVP scope. The result is a channel that actually gets used — not a vanity app.
Typical use cases for a mobile app or PWA.
We see six situations where going mobile — as an app or as a PWA — has the largest leverage. If you recognise yourself here, you are in the right place:
Customer app: self-service, booking, status
Customers book an appointment, open an order, follow status, file documents, or look at their contract. A lean app or PWA with clean login, well-behaved push, and a stable backend replaces three email loops per case.
Field-service and on-site app
Technicians, installers, care staff, inspectors, sales reps: open orders on the road, capture data, upload photos and signatures, post materials. Offline-capable, with deliberate sync to the ERP or order backend whenever connectivity returns.
Booking and self-service app
Appointments, slots, tables, rooms, courses, consultations — with calendar sync, waitlists, reminder push, and payment. A channel customers actually open, instead of a PDF form they fill out in 2024 and never again.
Internal mobile workflows
Staff log hours, damages, deliveries, checklists, safety inspections on the move. A mobile app frees up head office — and replaces clipboard, paper, and the “WhatsApp to the boss” process with something defensible.
Companion app for a product or device
A device, a sensor, a machine, a vehicle — and an app that handles setup, live data, diagnostics, updates, and notifications. Here the app is not nice-to-have, it is part of the product.
App MVP for a new product
You have an idea that needs to live on mobile — and you want to test it without pouring nine months and a quarter million euros into a full version. We ship a tight MVP on a few core journeys, usually on React Native or as a PWA, with a clear roadmap for what comes next.
Decision guide: PWA vs. React Native vs. native.
The most important decision is not made in code — it is made beforehand. We walk you through these six points before the first line is written, and they decide half the later cost:
Who is the audience and how often do they open the app?
A few rare visits per year (status checks, applications, bookings) usually point to a PWA — no store hurdle, no download, no update friction. Daily, intensive use with real engagement (field service, loyalty, daily workflows) almost always justifies a real app on React Native.
How much device and hardware does the app need?
Pure UI and API workflows are excellent territory for a PWA today. The moment you reach into camera, NFC, Bluetooth, precise background geolocation, native notifications, health or filesystem APIs, React Native (and, in edge cases, a native layer) is the more honest tool.
How important are the App Store and Play Store as a channel?
If store visibility, ratings, and “find us in the App Store” matter — e.g. for a consumer app, loyalty, or a product companion — the app belongs in the store. For internal and B2B workflows the store is often friction rather than value; then PWA plus internal distribution is the cleaner path.
Offline: can the app keep working without connectivity?
Field service, industry, logistics, sites without reception: offline is not negotiable. React Native (with a local DB like SQLite or WatermelonDB and a deliberate sync layer) is usually the more robust choice here. A modern PWA can do offline too, but its ceiling is lower for deep offline.
Team, time, and budget — what can you actually carry?
Two native code bases (iOS + Android) plus web are expensive and slow to iterate. React Native + Expo gives you one code base for iOS and Android, usually with much better time-to-market. A PWA is even faster and cheaper — when the requirements fit.
How tightly does the app hang on your existing backend?
An app is only as good as the backend behind it. When auth, data, roles, bookings, and notifications are new anyway, we plan the app and backend together. When an ERP/CRM/SaaS already exists, we describe upfront what the app, the backend, and the third-party system own — before anyone designs a screen.
Building blocks, stack, and architecture — what you actually get.
A p24.co mobile app is not “logo + three screens + some API”. Every block below is deliberately designed, documented, and handed over:
1. Mobile discovery & stack decision
Workflow, audience, devices, offline needs, push needs, store strategy, existing systems. Output: an honest “PWA vs. React Native vs. native” recommendation, an MVP scope, a risk list, and assumptions — before the first line of code.
2. App architecture: React Native + Expo or PWA
For native apps: React Native with Expo, TypeScript, typed API clients, clean navigation, theme system, modular structure. For PWAs: Next.js / React with service worker, manifest, installability, push support, and a real offline cache.
3. Backend integration & sync
API layer (REST or tRPC/GraphQL), integration with an existing backend or a fresh one (Node, .NET, Postgres). Clean data models, idempotency, and a real conflict strategy for offline sync. Whatever is created locally moves up cleanly at the next online moment.
4. Auth, roles & secure sessions
Login via email/password, magic link, OAuth/SSO, or single-tenant token. Roles and visibility (customer, employee, admin), secure token storage (Keychain/Keystore), session invalidation, optional biometrics.
5. Push notifications & inbox
Push via Expo Notifications, APNs/FCM, or web push. A clean opt-in flow, segmented sending, templating, in-app inbox read receipts, anti-spam rules. Notifications users actually want — not 14 a day because a marketing console has a send button.
6. Offline support & local storage
Local cache and, where it fits, a local DB (SQLite, WatermelonDB, MMKV), action queues, clean conflict rules, transparent UI indicators (“syncing”). The app does not break when the signal drops.
7. Analytics, crash reporting & feature flags
Privacy-aware analytics (Plausible, PostHog, or in-house), crash and error reporting (Sentry), feature flags for controlled rollouts. You see what is actually happening — not just when the support inbox overflows.
8. App Store / Play Store release & PWA distribution
App icons, splash, store listings (DE/EN), screenshots, privacy notices, privacy manifest, in-app purchases where needed, App Tracking Transparency. We handle the Apple and Google review rounds. For PWAs: clean installability, web manifest, optional internal rollout.
9. Documentation & handover
Architecture document, stack rationale, API contracts, build and release guide, store credentials handed back to you cleanly, developer onboarding docs. A new engineer — or a new vendor — is productive in days.
From app MVP to roadmap — the process.
Mobile projects almost always die at the same point: too much in the first release and no plan for what comes after. We approach it in clear phases — with a real MVP, a fast pilot, and a controlled rollout.
- 01
Discovery & MVP scope
Week 1–2Workflow mapping, audience, prioritised use cases, PWA vs. React Native decision, data-model sketch, assumptions, and non-goals. Output: a compact mobile brief, an MVP scope on 1–2 core journeys, a risk and effort list.
output → Mobile brief · MVP scope - 02
Design & clickable prototype
Week 2–4UX flows for the core journeys, wireframes, a clickable Figma prototype, a style and component set. Tested with real users or internal stakeholders. Changes happen here — not later in code.
output → Prototype · design system - 03
MVP build (React Native or PWA)
Week 4–10Implementation of the core journeys, API layer, auth, local storage, push integration, analytics, crash reporting. Weekly demos and TestFlight / Play Internal / PWA staging builds.
output → MVP build · TestFlight / Play Internal - 04
Pilot with real users
Week 10–12A controlled pilot with a selected group: first customers, a field-service team, one site. Telemetry live, feedback channel defined, bug-fix and UX-polishing loops daily. What we learn here is worth more than three internal stakeholder meetings.
output → Pilot · bug-fix & UX polish loop - 05
Store release / PWA rollout
Week 12–14App Store and Play Store listings, review rounds, privacy manifest, privacy texts. For PWAs: clean installability and, where useful, an internal distribution channel. A stable first version on the devices of the real audience.
output → Store release · PWA rollout - 06
Operation, iteration & roadmap
From week 14Go-live, telemetry and crash reports active, support and update process defined. Then roadmap-based iteration in short cycles: next journeys, new platforms, new modules — based on real usage data.
output → Live operation · roadmap setup
What “good” means for a mobile app, in practice.
You do not recognise a good app by its splash screen — you recognise it by what is still left three weeks into real use. This is the bar:
It actually gets opened
An app is only valuable if it gets opened after onboarding. We design for one clear, recurring reason — not for twelve features nobody uses.
Fast, quiet, no jank
Cold start under two seconds on real hardware, smooth list scrolling, transitions that feel native. No artificial loaders, no white screens, no animation theatre to mask a slow API.
Offline is not an error state
Actions get written into a local queue, are clearly marked as “syncing”, and move up automatically once connectivity returns. Conflicts are resolved, not swallowed.
Auth is robust and out of the way
Login works with real password managers, with biometrics where sensible, with magic link where it fits better. Sessions are stored securely, sign-out actually signs out, token refresh is invisible.
Push respects the user
Clear opt-in, clear frequency rules, segmented templates. An app does not send 14 push messages a day because a marketing tool has a send button — that is the fastest path to uninstall.
Updates and store reviews are a solved problem
Releases are reproducible, OTA updates (where allowed) shorten response time, store reviews are handled with real release notes — not “throw it at Apple and hope”.
Privacy, data, and founder accountability.
A mobile app sits on your customers’ or employees’ phones — it is closer to real data than almost any other software. p24.co is run by Dimitri Kronich from Krefeld, Germany. You get a direct technical counterpart with an EU base who really owns architecture, security, and privacy — not someone who delegates them downwards.
- 01Founder-level ownership — a direct line to the person who decides architecture and privacy.
- 02Based in Krefeld · Germany & EU — GDPR-aware delivery, EU backend hosting, clear processing grounds.
- 03Privacy-aware telemetry, transparent privacy manifests, App Tracking Transparency done correctly.
- 04Secure token and key storage (Keychain/Keystore), clear auth and session rules.
- 05A handover designed so another team could keep running your app — no lock-in.
Frequently asked questions about mobile app and PWA development.
PWA or native app — what is right for us?
It comes down to three things: how often users open the app, how deeply you need device features (camera, Bluetooth, push, offline), and how important App Store and Play Store are as a channel. For rare, less demanding use, a PWA is almost always the more honest choice. For daily, intensive use, hard offline requirements, or real device integration, React Native usually wins.
Why React Native and not “fully native” in Swift and Kotlin?
Because one code base for iOS and Android is significantly cheaper, faster, and more maintainable for 90% of business and MVP cases. React Native + Expo delivers UI and performance quality that is more than enough for the vast majority of apps. We keep native (Swift/Kotlin) for edge cases: deep hardware integration, very high performance demands, dedicated native modules.
What does an app MVP actually cost?
An honestly built app or PWA MVP with 1–2 core journeys, backend, auth, push, and a store/rollout path typically sits in the mid- to upper five-figure euro range. Larger projects with heavy offline support, multiple roles, complex backend, and a longer roadmap easily reach six figures. We make scope, assumptions, and risks transparent — no “fixed price” on top of half-defined requirements.
How long until the first version is in the store?
A realistic app-MVP corridor is 10–14 weeks from discovery to first store release, depending on scope, backend effort, and Apple/Google review cycles. A PWA version of the same idea is usually 4–6 weeks faster, because there is no store review.
Does the app work offline, and how does it sync with the backend?
Yes. For offline-relevant apps we use local storage (SQLite, WatermelonDB, or MMKV), write actions into a queue, and sync with the backend deliberately once connectivity returns. Conflicts are detected and resolved by clear rules — not silently overwritten.
Push, App Store, privacy: who handles the release headache?
We do. We work with you on Apple and Google developer accounts, then own store listings, privacy manifests, privacy texts, screenshots, App Tracking Transparency, and review rounds. You do not have to learn App Store Connect or the Play Console first.
What happens after launch — do you keep maintaining the app?
On request, we run operations: monitoring (crash reports, telemetry), bug-fix releases, store reviews, roadmap iteration, new modules. Equally, you can take over after the MVP with your own team — we ship documentation and setup so that path stays real.
What about privacy, GDPR, and data residency in Germany?
Backend components are hosted in the EU by default (Hetzner, AWS Frankfurt, Azure West Europe). Personal data is separated cleanly, processing is documented, and on the app side we use privacy-aware telemetry and transparent privacy manifests. The building blocks for data-processing agreements are in place.
Can you take over or rescue an existing app?
Yes — that is one of our typical cases. We start with an audit of the existing code base and architecture, document where things stand, name the risks, and propose a path: targeted refactoring, a phased migration onto a clean stack, or — when warranted — an honest rebuild with a clear data migration plan.
Related services and topics
Let’s pressure-test your app idea, honestly.
Tell us briefly who the app is for, what workflow it really serves, and which systems it needs to touch. You will get an honest, technical view — including a PWA vs. React Native recommendation — directly from the founder, without a sales layer and without buzzwords.