Eine Mobile-App, die wirklich genutzt wird — nicht eine, die im Store verstaubt.
Mobile Apps und Progressive Web Apps aus Deutschland: als ehrlicher Kanal in einem realen Workflow — Kunden-App, Außendienst-App, Buchung und Self-Service, interner mobiler Workflow oder Companion-App zu einem Produkt. Mit klarer Entscheidung zwischen PWA und React Native, sauberem MVP-Scope, Backend-Anbindung, Auth, Push, Offline und Store-Pfad. Founder-led aus Krefeld.
- PWA · React Native · Expo · TypeScript · Node / .NET-Backend
- App Store / Play Store-Release inkl. Review-Begleitung
- Standort Krefeld · Deutschland & EU · DSGVO-bewusst
Wann eine Mobile-App eine echte Investition ist — und wann nicht.
Eine App auf dem Home-Screen ist kein Marketing-Selbstzweck. Sie lohnt sich, wenn es einen wiederkehrenden Workflow gibt, der mobil deutlich besser läuft als am Browser-Tab: Auftragserfassung im Außendienst, Buchung und Termine, Bonusprogramm, Foto-Dokumentation vor Ort, Live-Status für Kund:innen, Companion-App zu einem Gerät oder Produkt. Wenn dieser Workflow nicht klar ist, ist eine native App fast immer die falsche Antwort — und eine gute Web-App oder Progressive Web App (PWA) der bessere erste Schritt. p24.co plant Mobile-Projekte deshalb von hinten: erst der Workflow, dann die Frage „PWA oder React Native“, dann der MVP-Scope. Ergebnis ist ein Kanal, der wirklich genutzt wird — keine Vanity-App.
Typische Anwendungsfälle für eine Mobile-App oder PWA.
Wir sehen sechs Situationen, in denen mobil — als App oder als PWA — den größten Hebel hat. Wenn Sie sich darin wiederfinden, sind Sie hier richtig:
Kunden-App: Self-Service, Buchung, Status
Kund:innen sollen einen Termin buchen, einen Auftrag anlegen, den Status verfolgen, Belege ablegen oder ihren Vertrag einsehen. Eine schlanke App oder PWA mit klarem Login, sauberen Push-Mitteilungen und stabilem Backend ersetzt drei E-Mail-Schleifen pro Vorgang.
Field-Service- und Außendienst-App
Monteure, Techniker, Pflege, Inspektoren, Außendienst: Aufträge unterwegs öffnen, Daten erfassen, Fotos hochladen, Unterschriften, Materialbuchung. Offline-fähig, mit kontrollierter Synchronisation an das ERP- oder Auftrags-Backend, sobald wieder Netz da ist.
Buchungs- und Self-Service-App
Termine, Slots, Tische, Räume, Kurse, Beratungen — inklusive Kalender-Sync, Wartelisten, Reminder-Push und Zahlung. Statt PDF-Formular ein Kanal, den Kund:innen wirklich öffnen — auch dann, wenn die Website nur sporadisch besucht wird.
Interne mobile Workflows
Mitarbeitende erfassen Stunden, Schäden, Wareneingänge, Checklisten, Sicherheitsbegehungen mobil. Eine Mobile-App entlastet Zentrale und Verwaltung — und löst Klemmbrett-, Zettel- und „Whatsapp-an-die-Chefin“-Prozesse sauber ab.
Companion-App zu einem Produkt oder Gerät
Eine Hardware, ein Sensor, eine Anlage, ein Fahrzeug — und eine App, die Konfiguration, Live-Daten, Diagnose, Updates und Benachrichtigungen übernimmt. Hier ist die App nicht „nice to have“, sondern Teil des Produkts.
App-MVP für ein neues Produkt
Sie haben eine Produktidee, die mobil leben soll — und wollen sie testen, ohne 9 Monate und 250.000 € in eine Vollversion zu kippen. Wir bauen einen sauberen MVP auf wenige zentrale User Journeys, in der Regel auf React Native oder als PWA, mit klarer Roadmap für danach.
Entscheidungs-Guide: PWA vs. React Native vs. native App.
Die wichtigste Frage entscheidet sich nicht im Code, sondern vorher. Diese sechs Punkte nehmen wir mit Ihnen vor der ersten Codezeile durch — und sie entscheiden über die Hälfte der späteren Kosten:
Wer ist die Zielgruppe und wie oft wird die App geöffnet?
Wenige seltene Besuche pro Jahr (z. B. Statusabfrage, Antrag, Buchung) sprechen klar für eine PWA — keine Store-Hürde, kein Download, keine Update-Friktion. Tägliche, intensive Nutzung mit hohem Engagement (Außendienst, Loyalty, tägliche Workflows) rechtfertigt fast immer eine echte App auf React Native.
Wie viel Gerät und Hardware braucht die App?
Reine UI- und API-Workflows lassen sich heute exzellent als PWA umsetzen. Sobald Sie tief in Kamera, NFC, Bluetooth, präzise Geolocation im Hintergrund, Native-Notifications, Health- oder Filesystem-APIs greifen, ist React Native (oder im Grenzfall ein nativer Layer) das ehrlichere Werkzeug.
Wie wichtig sind App Store und Play Store als Kanal?
Wenn die Sichtbarkeit im Store, Bewertungen, „im App Store finden“ und Marketing-Wert wichtig sind — z. B. für eine Verbraucher-App, Loyalty oder einen Produkt-Companion — gehört die App in den Store. Für interne und B2B-Workflows ist der Store oft eher Friktion als Vorteil; dann ist PWA + interne Verteilung sauberer.
Offline-Anforderung: kann die App ohne Netz arbeiten?
Außendienst, Industrie, Logistik, Außenstellen ohne Empfang: Offline-Funktionalität ist nicht verhandelbar. React Native (mit lokaler DB wie SQLite oder WatermelonDB und sauberem Sync-Layer) ist hier in der Regel die robustere Wahl. Eine moderne PWA kann das auch, ist aber für tiefes Offline limitierter.
Team, Zeit und Budget — was tragen Sie wirklich?
Zwei native Codebases (iOS + Android) plus Web sind teuer und langsam in der Iteration. React Native + Expo liefert eine Codebase für iOS und Android, oft mit deutlich besserer Time-to-Market. Eine PWA ist nochmal schneller und günstiger — wenn die Anforderungen passen.
Wie eng hängt die App an Ihrem bestehenden Backend?
Eine App ist nur so gut wie das Backend dahinter. Wenn Auth, Daten, Rollen, Buchungen und Notifications ohnehin neu sind, planen wir App und Backend gemeinsam. Existiert ein ERP/CRM/SaaS, beschreiben wir vorab klar, was App, was Backend und was Drittsystem leistet — bevor irgendwer designt.
Bausteine, Stack und Architektur — was Sie konkret bekommen.
Eine Mobile-App von p24.co ist nicht „Logo + drei Screens + irgendein API“. Jeder Baustein wird bewusst entworfen, dokumentiert und übergeben:
1. Mobile-Discovery & Stack-Entscheidung
Workflow, Zielgruppe, Geräte, Offline-Bedarf, Push-Bedarf, Store-Strategie, vorhandene Systeme. Output: ehrliche Empfehlung „PWA vs. React Native vs. nativ“, MVP-Scope, Risikenliste, Annahmen — vor der ersten Codezeile.
2. App-Architektur: React Native + Expo oder PWA
Für native Apps: React Native mit Expo, TypeScript, getypten API-Clients, sauberer Navigation, Theme-System, modularer Aufbau. Für PWAs: Next.js / React mit Service Worker, Manifest, Installierbarkeit, Push-Unterstützung und sauberem Offline-Cache.
3. Backend-Anbindung & Sync
API-Schicht (REST oder tRPC/GraphQL), Anbindung an ein bestehendes Backend oder Aufbau eines neuen (Node, .NET, Postgres). Klare Daten-Modelle, Idempotenz, Konflikt-Strategie bei Offline-Sync. Was lokal entstanden ist, geht beim nächsten Online-Moment kontrolliert nach oben.
4. Auth, Rollen & sichere Sessions
Login per E-Mail/Passwort, Magic-Link, OAuth/SSO oder Single-Tenant-Token. Rollen und Sichtbarkeit (Kund:in, Mitarbeiter:in, Admin), sichere Token-Speicherung (Keychain/Keystore), Session-Invalidierung, optional Biometrie.
5. Push-Notifications & Inbox
Push via Expo Notifications, APNs/FCM oder Web-Push. Sauberer Opt-in-Flow, segmentiertes Versenden, Templating, Lesebestätigung im App-Inbox, Anti-Spam-Regeln. Notifications, die der/die Nutzer:in wirklich will — nicht 14 pro Tag, weil die Marketing-Konsole eine Senden-Taste hat.
6. Offline-Support & lokale Datenhaltung
Lokaler Cache und ggf. lokale DB (SQLite, WatermelonDB, MMKV), Warteschlangen für Aktionen, klare Sync-Regeln bei Konflikten, transparente UI-Indikatoren („Eintrag wird synchronisiert“). Die App stürzt nicht ab, wenn das Funkloch kommt.
7. Analytics, Crash-Reporting & Feature-Flags
Datensparsame Analytics (Plausible, PostHog oder Eigenbau), Crash- und Error-Reporting (Sentry), Feature-Flags zum kontrollierten Ausrollen neuer Funktionen. Sie sehen, was wirklich passiert — und nicht erst, wenn der Support-Postkorb voll ist.
8. App Store / Play Store-Release & PWA-Verteilung
App-Icons, Splash, Store-Listings (DE/EN), Screenshots, Datenschutz-Erklärung, Privacy-Manifest, In-App-Käufe wo nötig, App Tracking Transparency. Wir begleiten Apple- und Google-Review-Runden. Für PWAs: saubere Installierbarkeit, Web-Manifest, optionaler interner Rollout.
9. Dokumentation & Übergabe
Architektur-Dokument, Stack-Begründung, API-Verträge, Build- und Release-Anleitung, Store-Credentials (sauber an Sie übergeben), Onboarding-Doku für Entwickler:innen. Ein neues Teammitglied — oder ein anderer Dienstleister — ist in Tagen einsatzfähig.
Vom App-MVP bis zur Roadmap — der Prozess.
Mobile-Projekte sterben fast immer am gleichen Punkt: zu viel im ersten Release und kein Plan für danach. Wir gehen das in klaren Phasen an — mit echtem MVP, schneller Pilot-Phase und kontrolliertem Ausbau.
- 01
Discovery & MVP-Scope
Woche 1–2Workflow-Mapping, Zielgruppe, Use-Cases priorisieren, Entscheidung PWA vs. React Native, Datenmodell-Skizze, Annahmen und Nicht-Ziele. Output: kompaktes Mobile-Briefing, MVP-Scope auf 1–2 Kern-Journeys, Risiko- und Aufwandsliste.
output → Mobile-Briefing · MVP-Scope - 02
Design & klickbarer Prototyp
Woche 2–4UX-Flows der Kern-Journeys, Wireframes, klickbarer Prototyp (Figma), Style- und Komponenten-Set. Test mit echten Nutzer:innen oder internen Stakeholdern. Anpassungen passieren hier — nicht später im Code.
output → Prototyp · Design-System - 03
MVP-Build (React Native oder PWA)
Woche 4–10Implementierung der Kern-Journeys, API-Schicht, Auth, lokale Datenhaltung, Push-Integration, Analytics, Crash-Reporting. Wöchentliche Demos und Testflight-/Play-Internal- bzw. PWA-Staging-Builds.
output → MVP-Build · Testflight / Play Internal - 04
Pilot mit echten Nutzer:innen
Woche 10–12Kontrollierter Pilot mit ausgewähltem Kreis: erste Kund:innen, ein Außendienst-Team, ein Standort. Telemetrie aktiv, Feedback-Kanal definiert, Bugfix- und UX-Polishing-Schleifen täglich. Was wir hier lernen, ist mehr wert als drei interne Stakeholder-Meetings.
output → Pilot · Bugfix- & UX-Polish-Schleife - 05
Store-Release / PWA-Rollout
Woche 12–14App-Store- und Play-Store-Listings, Review-Runden, Privacy-Manifest, Datenschutz-Texte. Bei PWAs: saubere Installierbarkeit, ggf. interner Verteilungskanal. Stabile Erstversion auf den Geräten der echten Zielgruppe.
output → Store-Release · PWA-Rollout - 06
Betrieb, Iteration & Roadmap
ab Woche 14Go-Live, Telemetrie und Crash-Reports aktiv, Support- und Update-Prozess definiert. Anschließend roadmap-basierte Weiterentwicklung in kurzen Zyklen: nächste Journeys, neue Plattformen, neue Module — auf Basis echter Nutzungsdaten.
output → Live-Betrieb · Roadmap-Setup
Was eine wirklich gute Mobile-App ausmacht — unsere Messlatte.
Eine gute App erkennt man nicht am Splash-Screen, sondern an dem, was nach drei Wochen Nutzung übrig bleibt. Das ist unsere Messlatte:
Sie wird wirklich geöffnet
Eine App ist nur wertvoll, wenn sie nach dem Onboarding noch geöffnet wird. Wir designen für genau einen klaren, wiederkehrenden Grund — nicht für zwölf Features, die nie genutzt werden.
Schnell, ruhig, ohne Ruckler
Cold-Start unter 2 Sekunden auf realer Hardware, Listen scrollen flüssig, Übergänge fühlen sich nativ an. Keine künstlichen Loader, keine Whitescreens, keine Animations-Theater nur, um eine API zu kaschieren.
Offline ist kein Fehlerfall
Aktionen werden in eine lokale Warteschlange geschrieben, klar als „wird synchronisiert“ markiert und gehen automatisch nach oben, sobald wieder Netz da ist. Konflikte werden gelöst, nicht verschluckt.
Auth ist robust und nicht im Weg
Login funktioniert mit echten Passwortmanagern, mit Biometrie wo sinnvoll, mit Magic-Link wo besser. Sessions sind sicher gespeichert, abmelden bedeutet abmelden, Token-Verlängerung passiert unsichtbar.
Push respektiert die Nutzer:innen
Klares Opt-in, klare Frequenzregeln, segmentierte Templates. Eine App schickt nicht 14 Pushes am Tag, weil ein Marketing-System eine Senden-Taste hat — das ist der schnellste Weg zum Deinstall.
Updates und Store-Reviews sind ein gelöstes Problem
Releases sind reproduzierbar, OTA-Updates (wo möglich) verkürzen Reaktionszeiten, Store-Reviews werden mit echten Build-Notes begleitet, statt sie an Apple/Google „mal hinzuwerfen“.
Datenschutz, Privacy und Founder-Verantwortung.
Eine Mobile-App liegt auf den Telefonen Ihrer Kund:innen oder Mitarbeitenden — sie ist näher an realen Daten als fast jede andere Software. p24.co wird von Dimitri Kronich aus Krefeld geführt. Sie haben einen direkten technischen Ansprechpartner mit deutschem Standort, der Architektur, Sicherheit und Datenschutz wirklich verantwortet — statt sie nach unten zu delegieren.
- 01Founder-Level Verantwortung — direkter Draht zu der Person, die Architektur und Datenschutz entscheidet.
- 02Standort Krefeld · Deutschland & EU — DSGVO-bewusste Umsetzung, EU-Backend-Hosting, klare Verarbeitungsgrundlagen.
- 03Datensparsame Telemetrie, transparente Privacy-Manifeste, App Tracking Transparency korrekt umgesetzt.
- 04Sichere Token- und Schlüssel-Speicherung (Keychain/Keystore), klare Auth- und Session-Regeln.
- 05Übergabe so, dass auch ein anderes Team Ihre App weiterführen könnte — keine Abhängigkeitsfalle.
Häufige Fragen zur Mobile-App- und PWA-Entwicklung.
PWA oder native App — was ist für uns richtig?
Das hängt an drei Punkten: Wie oft öffnen Ihre Nutzer:innen die App, wie tief brauchen Sie Geräte-Features (Kamera, Bluetooth, Push, Offline) und ob App- und Play-Store als Kanal wichtig sind. Für seltene, weniger anspruchsvolle Nutzungen ist eine PWA fast immer die ehrlichere Wahl. Für tägliche, intensive Nutzung, harte Offline-Anforderungen oder echte Geräte-Integration ist React Native in der Regel besser.
Warum React Native und nicht „richtig nativ“ in Swift und Kotlin?
Weil eine Codebase für iOS und Android in 90 % der Business- und MVP-Fälle deutlich günstiger, schneller und besser wartbar ist. React Native + Expo liefert heute UI- und Performance-Qualität, die für die allermeisten Apps völlig ausreicht. Native (Swift/Kotlin) heben wir für Spezialfälle auf: tiefe Hardware-Integration, sehr hohe Performance-Anforderungen, eigene Native-Module.
Was kostet ein App-MVP wirklich?
Ein ehrlich gebauter App- oder PWA-MVP mit 1–2 Kern-Journeys, Backend-Anbindung, Auth, Push und Store-/Rollout-Pfad bewegt sich typischerweise im mittleren bis oberen fünfstelligen Bereich. Größere Projekte mit umfangreicher Offline-Funktionalität, mehreren Rollen, komplexem Backend und längerer Roadmap landen schnell im sechsstelligen Bereich. Wir machen Scope, Annahmen und Risiken transparent — keine „Festpreise“ auf Basis halber Anforderungen.
Wie lange dauert es bis zur ersten Version im Store?
Ein realistischer App-MVP-Korridor liegt bei 10–14 Wochen von Discovery bis erstem Store-Release, abhängig von Scope, Backend-Aufwand und Review-Zyklen bei Apple und Google. Eine PWA-Version derselben Idee ist meist 4–6 Wochen schneller live, weil Store-Review entfällt.
Funktioniert die App offline und wie wird mit dem Backend synchronisiert?
Ja. Für offline-relevante Apps nutzen wir eine lokale Datenhaltung (SQLite, WatermelonDB oder MMKV), schreiben Aktionen in eine Warteschlange und synchronisieren kontrolliert mit dem Backend, sobald wieder Netz da ist. Konflikte werden erkannt und nach klaren Regeln aufgelöst — nicht stillschweigend überschrieben.
Push, App Store, Privacy: wer kümmert sich um den Release-Krampf?
Wir. Apple- und Google-Developer-Accounts begleiten wir gemeinsam mit Ihnen, Store-Listings, Privacy-Manifeste, Datenschutz-Texte, Screenshots, App Tracking Transparency und Review-Runden gehören zur Lieferung. Sie müssen nicht erst lernen, wie App Store Connect oder die Play Console funktionieren.
Was passiert nach Launch — pflegen Sie die App weiter?
Auf Wunsch übernehmen wir den weiteren Betrieb: Monitoring (Crash-Reports, Telemetrie), Bugfix-Releases, Store-Reviews, Roadmap-Iterationen, neue Module. Genauso können Sie nach dem MVP an ein eigenes Team übergeben — Doku und Setup liefern wir so, dass das machbar bleibt.
Wie ist es mit Datenschutz, DSGVO und Daten in Deutschland?
Backend-Komponenten hosten wir standardmäßig in der EU (Hetzner, AWS Frankfurt, Azure West Europe). Personenbezogene Daten werden klar getrennt, Verarbeitungen dokumentiert, App-seitig nutzen wir datensparsame Telemetrie und transparente Privacy-Manifeste. Bausteine für Auftragsverarbeitungsverträge stehen bereit.
Können Sie auch eine bestehende App übernehmen oder retten?
Ja, das ist einer unserer typischen Fälle. Wir starten mit einem Audit der bestehenden Codebase und der Architektur, fixieren den Zustand, identifizieren Risiken und schlagen einen Pfad vor: zielgerichtetes Refactoring, schrittweise Migration auf einen sauberen Stack oder — wenn nötig — ehrlicher Neu-Aufbau mit klarer Datenmigration.
Verwandte Leistungen und Themen
Lassen Sie uns Ihre App-Idee ehrlich durchrechnen.
Erzählen Sie kurz, für wen die App ist, welchen Workflow sie wirklich bedient und welche Systeme sie berühren muss. Sie bekommen eine ehrliche, technische Einschätzung — inkl. PWA-vs.-React-Native-Empfehlung —, direkt vom Gründer, ohne Vertriebsschicht und ohne Buzzwords.