Halcrow provided a dedicated "dev pod"—a cross-functional team embedded directly in BankTech's operations:

Team structure:

• 2 mobile developers (iOS + Android native apps)

• 2 backend engineers (API layer, database, integration)

• 1 QA specialist (security testing, transaction integrity, regulatory compliance)

• 1 product lead (BankTech/Halcrow interface, requirements → user stories)

Critical embedding elements:

• Daily standups with BankTech stakeholders: Not "status reports." Real coordination on blockers, decisions, trade-offs.

• Weekly venue visits during pilot: Embedded team physically present at ALH pilot locations. Watch patrons use the app. See where confusion happens. Fix it immediately.

• Direct access to BankTech's payment infrastructure: No "open a ticket to integrate." We had sandbox environment access, then production access after security review.

• Shared Slack channels: Real-time communication. BankTech product team, Halcrow dev pod, venue operations—all in same channels.

Law 3 (Direct Infrastructure Access): We didn't integrate via APIs from a distance. We worked inside BankTech's infrastructure. When something broke, we could diagnose and fix it directly instead of playing telephone through support tickets.

Build Structure: Phased Rollout with Real-World Testing

Phase 1: MVP Build (February–June 2023)

Objective: Working mobile app + web platform ready for internal testing.

4-month sprint:

• iOS app (Swift native)

• Android app (Kotlin native)

• Web platform (React frontend, Node.js backend)

• MIMO card integration (physical card <-> digital balance linkage)

• GreenID integration (KYC verification for new users)

• Payment gateway integration (load funds, cash out)

• Basic regulatory reporting (transaction logs, spend patterns)

Technical decisions made in this phase:

1. Native apps vs. hybrid: Chose native (Swift/Kotlin) over React Native because performance mattered. Patron expects instant balance updates when they tap the card. Any UI lag = perception of "something's wrong."

2. Real-time sync architecture: WebSocket connections for live balance updates. Polling would have worked but felt sluggish. Real-time was critical for user confidence ("my money is actually moving").

3. Offline-first design for venues: Venues have unreliable WiFi. App needed to queue transactions locally, sync when connection restored. Gaming machines can't wait for network round-trips—transaction has to happen, then sync later.

4. Security-first for financial data: PCI-DSS compliance from day one. All financial data encrypted at rest and in transit. KYC verification via GreenID (third-party service) to avoid building identity verification in-house.

Phase 2: Pilot Launch (July–October 2023)

Objective: Launch in 3 ALH venues, test with real patrons, iterate based on real behavior.

Critical insight from venue visits: Patrons didn't read instructions. They'd tap the MIMO card, see nothing happen (because they hadn't opened the app first), assume it was broken.

Fix: Change onboarding flow. First-time users forced through a "tap your card now" step while app is open. Patron sees balance update in real-time. Aha moment. "Oh, that's how it works." Drop-off during onboarding went from 40% to 12%.

Other real-world fixes:

• Balance display size: Patrons couldn't see their balance from pocket distance. Made font 3x larger on main screen.

• Transaction confirmation: Patrons wanted explicit "you just spent $25" notifications. Added push notifications for every transaction over $10.

• Cash-out friction: Original design: 3 taps to cash out. Patron feedback: "I'm drunk, I just want my money." Reduced to 1 tap + PIN confirmation.

Law 9 (Incremental Exposure Reduction): We didn't launch in 50 venues simultaneously. 3 venues first. Learn. Fix. Then scale. Each venue taught us something—second venue had different POS system, required adapter. Third venue had older gaming machines, needed firmware update.

Phase 3: Scale Rollout (November 2023–August 2024)

Objective: Expand to 20+ ALH venues, onboard additional venue operators, stabilize for national rollout.

By this phase, the product was mature. Most work shifted from "build new features" to:

• Infrastructure scaling (10,000 patrons → 50,000 patrons without performance degradation)

• Venue-specific integrations (every venue had slightly different POS/gaming machine configurations)

• Regulatory compliance reporting (automated generation of reports for different state regulators)

• Financial reconciliation (end-of-day settlement across multiple venues, banks, payment processors)

Key technical evolution:

• DNS migration: Original infrastructure had single points of failure. Migrated to more resilient setup (documented in "Banktech DNS Ecosystem Migration" Sept 2024).

• Monitoring and alerting: Built real-time dashboard for BankTech operations team. If transaction success rate dropped below 95% at any venue, alerts fired immediately.

• Multi-venue coordination: Patron could load balance at Venue A, spend at Venue B, cash out at Venue C. Backend had to track cross-venue transactions, handle edge cases (what if Venue B's network is down when patron tries to spend?).