QueueHamster is the first product Datanation has shipped under our own name — a virtual queue management SaaS for independent service businesses, live in production since May 2026. It runs today in barbershops, clinics, salons, cafés, vets, and pharmacies. Customers scan a QR code to join the queue. Staff manage the room from a single dashboard. No app install, no hardware.
Below are the four engineering decisions that mattered most, the surprise we didn’t see coming, and the one decision we’d reverse if we were starting again.
The hardest decision — two apps, two platforms, one small team
The hardest engineering problem in QueueHamster wasn’t the queue state machine, the realtime sync, or the staff dashboard. It was the org-economics problem hidden inside the technical question: how do you ship two production-quality mobile apps without doubling the team, doubling the codebase, or doubling the QA surface?
Two answers, applied together.
React Native + Expo on the New Architecture, as the structural lever. One codebase, two platform binaries, roughly 90% shared. The New Architecture (Fabric, JSI, TurboModules) closed most of the performance gap that justified separate native codebases two years ago. We never seriously considered shipping QueueHamster as two native codebases. We treated that path as a 2× cost we didn’t need to pay — and the gap between “we could afford a 2× cost” and “we should pay one” is the distance between a product that ships and one that doesn’t.
The BMAD methodology, as the development operating system. The bigger and harder-to-talk-about lever was applying the BMAD method — PRD → architecture → epics → stories → dev → review, with each step yielding artifacts the next step actually uses, not slide decks that get rewritten. The honest answer to “how does a small team ship two apps?” is that the stack choice matters less than the operating cadence around it. React Native is a tool. A disciplined methodology is what turns the tool into shipped product.
We mention BMAD by name not because it’s the only methodology that works, but because picking some explicit methodology — and following it — is the part of the answer most “small-team velocity” stories leave out.
The surprise — realtime sync in low-signal spots
We expected the queue state machine itself to be the hard problem. The unexpected harder problem was offline and low-signal behavior in the customer’s hands.
QueueHamster runs in places where signal is bad: the back room of a busy clinic, the inside of a strip-mall salon, an urban basement barbershop. The customer’s phone needs to maintain a credible queue position when the connection drops for 90 seconds at a time. The staff dashboard needs to write authoritative state when the customer’s view hasn’t refreshed in two minutes.
This is the kind of problem that’s invisible in a demo. It only shows up in real customers’ hands. We handled it with:
- Optimistic UI on the customer side, with reconciliation when the connection returns
- Server-authoritative writes from the staff side — staff actions are the source of truth, customer views are projections
- Conflict resolution that resolves toward fairness — if the customer’s local view says position #3 but the server says #5 because they missed a refresh, we surface the gap clearly rather than papering over it
If we’d skipped this work, QueueHamster would have demoed beautifully and failed in the second week of production.
For a realtime product, the offline path is the product, not a fallback.
The design philosophy — scale at minimal cost
Every architectural decision in QueueHamster ran through one filter: what does this cost per customer at 10× the current scale?
This sounds like a finance question. It’s actually a coupling question. The most expensive thing a small product can do is couple its marginal cost to vendor pricing tiers that don’t match its growth curve. Once that coupling exists, growth makes the unit economics worse, not better — and the team starts optimizing for cost control instead of product.
We avoided that coupling by:
- Choosing Firebase as the backend — pay-per-use serverless, no idle cost, automatic scaling primitives where they earned their place (Firestore, Cloud Functions, Auth, Cloud Messaging)
- Refusing any third-party service in the request hot path that priced super-linearly with active users
- Treating SMS as an explicit add-on rather than a baseline — keeps notification cost proportional to opted-in customers, not all customers
The result is that QueueHamster’s cost per active business is roughly flat across its current customer count. That’s the discipline we’d recommend in any product engagement at this stage — and the discipline we apply to our own.
The stack — end-to-end, prototype to production
QueueHamster runs on React Native + Expo + Firebase. We picked the stack because it’s one of the few that gets a product from initial prototype to production deployment without re-architecting in between.
The traditional pattern is to pick different stacks for different scales — a “scrappy MVP” stack to ship in eight weeks, then a “real” stack to rewrite into when you raise a Series A. We don’t believe in that pattern. It throws away the institutional learning encoded in the prototype, and it usually arrives at a “real” stack that’s only marginally better than what you had.
The RN + Expo + Firebase stack works because:
- EAS Workflows make the iOS and Android build pipelines genuinely production-grade from day one
- Expo’s managed workflow handles 90% of native concerns;
expo-dev-clientand custom native modules cover the rest - Firebase’s tier-zero services (Auth, Firestore, Functions, Hosting, Cloud Messaging) are production-grade at the free tier and stay coherent well into paid scale
- The whole thing deploys with one toolchain — no separate mobile-build platform, no separate backend-hosting story, no integration tax between them
This is the same stack we recommend to Labs pillar clients for greenfield mobile work. We don’t recommend it because it’s fashionable. We recommend it because it’s what we run when we have skin in the game.
The one we’d do differently — SMS fallback in v1
We shipped QueueHamster v1 with push notifications as the primary “your turn is up” surface. SMS came in v2. We should have shipped SMS in v1.
Push notifications are an unreliable substrate for the QueueHamster customer demographic — phone-OS permission states, iOS notification grouping rules, low-battery aggressive suppression — all of it conspires to drop notifications the moment they matter most. SMS is annoying for the average mobile app, but exactly right for a queue notification: it always lands, it works without app install, and it doesn’t depend on the customer’s OS having granted a permission three weeks ago.
We delayed it because we read SMS as a per-message cost line item, and at v1 economics every per-message cost looks expensive. We were optimizing the wrong thing. The cost of a missed customer notification is higher than the cost of an SMS by an order of magnitude — in both customer-experience terms and in churn terms.
If we’d applied our own “scale at minimal cost” philosophy more carefully, we would have noticed that SMS is a minimal cost when it replaces a missed turn. We didn’t. Lesson learned, fixed in v2 — and now built into our default recommendation for any client building a customer-facing notification pattern from the Labs pillar.
What this is, and isn’t, a case for
This isn’t a case for React Native, or for Firebase, or for BMAD specifically. The right stack and the right methodology depend on the work. This is a case for picking an explicit one of each, and following it. Most small-team mobile builds that drift are drifting because they never made those choices on purpose.
Every claim in this piece — the parallel-app discipline, the offline-first sync, the cost-coupling discipline, the stack rationale, the SMS lesson — comes from running QueueHamster in production with real customers. It’s the same engineering bar we apply to client work. The Labs pillar is the place where this approach gets applied to your codebase, not ours.