The app looked finished until someone used it in a lift.
The signal dropped halfway through a form. The user reopened the app and found two records, neither complete. A permissions prompt had appeared before the app explained why it needed access. The demo never covered any of it.
Mobile quality lives in interruptions, devices, stores, and recovery, not only the happy-path screen recording.
Mobile proof
- 50,000
- EventRaft users in six months
- Recorded case-study result
- 20 weeks
- native iOS and Android delivery
- Event platform scope
- 95%
- user satisfaction
- Client-reported outcome
The EventRaft case study documents the native apps, 20-week scope, and reported results. It does not imply that every mobile product needs native development or will reach the same adoption.
A mobile app needs a mobile reason.
If the full job works in a browser, avoid adding store review, installed-version support, and device fragmentation without a user benefit.
A fit01The journey depends on a camera, location, sensors, Bluetooth, offline work, or background activity.
02Users act often enough that an installed, authenticated experience removes meaningful friction.
03Push notifications are part of a defined action loop, not a retention wish.
Not a fit01The product is mainly dashboards, long forms, administration, or occasional access.
02A responsive web application can complete the same outcome cleanly.
03Demand and the first valuable user action have not been tested yet.
Scope
Mobile products we develop
01Cross-platform iOS and Android
One Flutter or React Native product can cover shared workflows on both platforms, so teams can release and maintain the common journey together.
Swift and Kotlin support experiences where platform-specific hardware, performance, background work, or interface behaviour carries the product value.
03Offline and interrupted workflows
Local state, queues, conflict rules, retries, and visible sync status let field users keep working without creating silent duplicates.
04Backend and device integrations
Connect identity, payments, messaging, media, maps, Bluetooth, health, or business APIs with permissions and failure handling designed into the user path.
05Store delivery and product signals
Prepare builds, privacy details, review evidence, release tracks, crash monitoring, and journey analytics so launch is observable rather than ceremonial.
Cross-platform vs native mobile
| Cross-platform | Native |
|---|
| Best fit | Mostly shared workflows and UI across iOS and Android | Platform-specific hardware, performance, or background behaviour |
| Code model | Shared product code with platform-specific modules where needed | Separate Swift and Kotlin applications |
| Release work | Shared product changes, two store releases | Two development and release paths |
| Decision rule | Use unless evidence requires deeper platform control | Use when platform differences create product value |
How it works
From mobile job to store release
- Phase 1
01Prove the phone belongs in the workflow
Map user context, device features, connectivity, platforms, backend, and the first valuable task.
- Phase 2
02Choose native or cross-platform
Test hardware, performance, UI, team, release, and maintenance constraints before committing to the architecture.
- Phase 3
03Validate on real devices
Use testing tracks to check permissions, interruptions, sync, accessibility, performance, and failure states.
- Phase 4
04Submit, monitor, and improve
Prepare store evidence, release the approved build, monitor crashes and journeys, and expand after real usage.
Risk
Mobile failures that do not appear in the demo
- Permissions arrive without context
- Explain the user benefit before asking for camera, location, notification, or health access, and support a denied state.
- Offline means storing a draft
- Reliable offline work also needs queues, retries, conflict rules, identity, visible sync state, and duplicate prevention.
- Testing stops at simulators
- Real devices expose memory, network, keyboard, sensor, permission, and OS-version behaviour that simulators miss.
- Store review is treated as guaranteed
- Prepare policy evidence and submission materials, but keep contingency because Apple and Google control review timing and decisions.
Start with named countries, not a Europe-wide assumption. Country and language
scope can change privacy prompts, analytics and advertising SDKs,
accessibility testing, payment authentication, store metadata, customer
support, and the evidence a buyer or reviewer expects. The architecture should
separate translatable content from code and document every provider that can
access user data. The client and its qualified advisers approve applicable
legal, tax, consumer, and sector requirements.
Regional proof also stays specific. The City Break Apartments
platform
combined a Dublin booking website with a keyless mobile journey. The
Concurrences app supported a
Paris legal publisher. Those projects show European delivery experience, not
one configuration that fits every European launch.
Scope and price
A focused mobile app starts at $25,000.
Start with one complete journey, the device features it needs, backend connection, store submission, and monitoring.
Starts at $25,000A focused first release usually takes 8 to 14 weeks. Native scope, offline sync, hardware, media, and a new backend can extend the plan.
A wider product is priced after platforms, devices, backend ownership, integrations, store accounts, and release risks are mapped.
Fixed-price phase
Once the first phase is scoped, its price is locked in writing. New features enter through an agreed change.
Post-launch support
Eight weeks of support are included for defects within the agreed scope. Store decisions remain controlled by Apple and Google.
