● Labs pillar · Cross-platform · Brownfield-first · Senior-only
Cross-platform mobile
that ships fast — and into
the apps you already have.
React Native + Expo on the New Architecture for greenfield. expo-brownfield
where there's a Swift or Kotlin codebase already running. Kotlin Multiplatform when strict performance
is the point. Native where AR/VR or OS-specific behavior is the work. We pick the right tool for
the actual problem — and we ship our own products to prove we can.
We ship our own.
QueueHamster is a virtual queue management SaaS for independent service businesses — barbershops, clinics, salons, cafés, vets, pharmacies. Customers scan a QR code to join the queue, get live position updates, and get notified when it's their turn. Live in production since May 2026, built by the Datanation team on the same React Native + Expo + Firebase stack we recommend for greenfield mobile engagements.
Most consulting firms talk about shipping mobile. Few do. QueueHamster is what it looks like when we apply our own engineering bar to our own product.
QueueHamster
Virtual queue management for independent service businesses.
Live in production since May 2026.
Stack: React Native · Expo · Firebase
Brownfield-first.
Most mobile shops will quote you a ground-up rewrite. We won't — unless that's actually the right answer.
Enterprises don't usually need a new app. They need to extend the app they already have. They need to ship a new feature on iOS and Android without three teams shipping it three times. They need to add a React Native surface inside a five-year-old Swift codebase without breaking what works.
expo-brownfield (released in 2026) made this dramatically more tractable.
It's an isolated integration pattern — React Native modules live alongside your existing native
screens, share state cleanly, and ship independently. We use it heavily. We have opinions about
where it fits and where it doesn't.
If you have a working native app and a feature backlog that's twice as long as your team, brownfield integration is almost always the right answer. It's also almost always the answer mobile shops won't sell you, because rewrites bill more.
Five decisions. Not five frameworks.
"Use React Native" isn't a stack decision; it's a slogan. The real decision is under what conditions. Here's how we make the call.
| # | Condition | Stack | Why |
|---|---|---|---|
| 1 | Greenfield consumer or enterprise mobile | React Native + Expo on the New Architecture (Fabric, JSI, TurboModules), EAS Workflows for CI/CD | Default. The "RN is slow" objection died with the New Architecture in early 2026. Ships fast, maintains well, recruits broadly. |
| 2 | Integration into an existing Swift / Kotlin codebase | `expo-brownfield` (Isolated pattern) | The 2026 specialty most mobile shops won't sell. Add RN surfaces without a full rewrite. |
| 3 | Strict UI-performance enterprise app, deep platform integration | Kotlin Multiplatform (KMP) | Now officially recommended by Google for Android/iOS code sharing. Production adopters include McDonald's, Duolingo, Forbes, Philips. The right choice when "near-native" isn't enough. |
| 4 | AR/VR, gaming, or deep OS-specific behavior (visionOS, advanced widgets, on-device ML, etc.) | Native Swift / Kotlin | Cross-platform is the wrong abstraction when you need to ship a platform-specific OS feature within 30 days of release. |
| 5 | You're considering a mobile app but haven't validated demand | A responsive web app first | Most companies ship native apps too early. If your hypothesis is unproven, prove it in the browser before paying the mobile-app tax in distribution, store reviews, and update cycles. |
Mobile Foundations Audit.
Ten days. Fixed scope. No prerequisites.
A 10-day engagement for teams with an existing mobile app and questions about what to do next. We tear down the current codebase (build pipeline, dependency hygiene, architecture, performance, accessibility, store-readiness), benchmark against the 2026 standard, and deliver a written modernization roadmap.
Deliverable: a teardown report · a 12-month modernization roadmap (greenfield vs. brownfield vs. native split, with reasoning) · an honest answer on whether your current team can ship it, or whether you need help.
Request a scoped proposal →The work that follows.
Once the foundation is clear, the engagement shapes around the work:
- RN + Expo greenfield builds — consumer or enterprise mobile, ships on the New Architecture, full EAS Workflows CI/CD from day one.
- Brownfield RN integration — adding React Native surfaces to existing Swift or Kotlin codebases via the expo-brownfield isolated pattern.
- Kotlin Multiplatform migrations — for teams where near-native UI performance is non-negotiable and the team has the Kotlin fluency to maintain it.
- Mobile CI/CD modernization — replacing handrolled GitHub Actions pipelines with EAS Workflows; release engineering done properly.
- Native module development — when the cross-platform layer doesn't reach the OS feature you need; we write the bridge.
- Mobile rescue projects — apps stuck in a release loop, crashing in the wrong cohort, or rejected by the App Store for reasons no one on the team can name. Honest answer up front about whether it's salvageable in the engagement window.
What we don't do.
A short list, because saying no is part of the work:
- We don't recommend Flutter. We've evaluated it more than once; for our client profile, React Native + Expo is the better answer. The right answer for you might still be Flutter — we'd tell you.
- We don't do total rewrites when brownfield integration will do.
- We don't ship Legacy Architecture React Native in 2026. The New Architecture is mandatory in our greenfield engagements.
- We don't "go native" just to be native.
- We don't ship a mobile app when a responsive web app is the right answer.
Two engineers. One honest answer.
A 30-minute briefing with the people who'd actually do the work. If your app is fine and you don't need us, we'll tell you. If a rewrite is the wrong move, we'll tell you that too — and probably tell you what to do instead.
Request a scoped proposal →