Skip to content

Case 01 · Mobility · 2026 – present

Tazz.

A ride-hailing app in Brazil. I architected and built the new Expo app and its new Workers from scratch, with AI agents writing the code in parallel. I also moved the backend’s compute to Cloudflare and shipped the support agent and PIX.

Fact sheet

Role
Architecture, app, backend and AI
Period
2026 – present
Stack
TypeScript · Expo · Cloudflare Workers · Durable Objects · Queues · Postgres
AI
In production · Agent under human review
New app
Pre-launch · Expo, to replace the Flutter app in the stores
  • New app

    Expofrom scratch, with its own auth, hub and API

  • Migration

    100+ → 8Cloud Functions → Cloudflare Workers in ~47.5 h

  • Payments

    Sep 2026PIX in production

01 / Problem

A quota ceiling and an app tied to Firebase.

20vCPU · fixed quota · São Paulo

The backend ran on ~158 Cloud Functions on GCP and hit the fixed 20 vCPU quota in the São Paulo region, with the app live.

Moving the backend was not enough to leave GCP. The Flutter app talked straight to Firestore, Realtime Database, Storage and Firebase Auth through the SDK, even in native code.

02 / Context

Swapping the engine mid-flight.

First I swapped the HTTP compute: it moved to Cloudflare Workers, and the data stayed on GCP. In Sep 2026, I started a new Expo app from scratch, as a proof of concept, that never talks to Firestore, Realtime Database or Firebase Auth directly. On Sep 8, it became the planned replacement for the Flutter app in the stores. In the meantime, the Flutter app stays in production.

03 / My role

End-to-end engineering.

3.1

AI and backend.

  • Support agent with tools, guardrails, LLM‑as‑judge and evals
  • Orchestrating the coding agents that built the new app and Workers
  • Strangler‑fig migration to Cloudflare Workers
  • PIX with Asaas, on the double-entry ledger
3.2

New app.

  • Expo app from scratch, for riders and drivers
  • In-house auth, a realtime hub and an API on Workers over Postgres
  • Component library for the new app, with tokens and 2 themes
  • New admin app and support console, with human handoff

04 / Architecture

Two apps on the same edge.

Fig. 01New app
  1. AppExpo · riders and drivers
  2. In-house Workersauth · API · rides /v1Realtime hubDurable Object per city · WebSocket
  3. PostgresPlanetScale · Hyperdrive

Built for OTA from the first build · Firebase Auth only checks the password on the first login

Fig. 02Migration
  1. AppFlutter
  2. GatewayWorkerRoutes not migratedLegacy functionsGCP
  3. Domain Workers
  4. Firestore and Realtime DatabaseGCP

During the port

Fig. 03Support
  1. ChannelsWhatsApp, Instagram, app, website, email
  2. SupportQueues + DO per conversation
  3. AgentLLM via AI Gateway · WhatsApp and app
  4. Toolslookups, notes and handoff · allowlist
  5. Human operatorreviews and sends · handoff

05 / Where AI comes in

In customer support.

Model
OpenAI via AI Gateway, with fallback.
Tools
Data and knowledge base lookups, internal notes and handoff, with an allowlist and auditing. There is no tool for money, sign-up or cancellation. At most 3 tool-call rounds.
Guardrails
Layered checks, LLM‑as‑judge and redaction of personal data.
Evals
Offline evals with datasets, a gate and a comparison of 4 models. Shadow and canary rollout.
Status
In productionUnder human review: the AI writes a draft, and a person on the team sends, edits or discards it.

06 / How it was built

A team of agents, with human gates.

I started the app from scratch on Sep 4, 2026. A discovery run with 12 agents read the Flutter app and the Expo SDK 57 docs, and wrote specs with facts cited by file and line.

Then coordinator agents, one after another, ran a backlog of ~200 workstreams in parallel sessions, each in its own worktree, and merged the results. The first integration reached main on Sep 8, 2026.

Fig. 04Building with agents
  1. Discoveryreads the Flutter app
  2. Backlogworkstreams in waves
  3. Coordinatoragent · merges
  4. Workstreamsparallel · 1 worktree each
  5. Reviewanother provider per workstream
  6. Human gatesdatabase, main and stores
Architecture
I set the architecture in the app spec: in-house auth, accounts in Postgres, a realtime hub and OTA support from the first build.
Evidence
Each workstream ends with one proof per acceptance criterion. The coordinator runs the checks again before merging.
Review
Each workstream is reviewed by a model from another provider. On top of that, 4 consolidated rounds gave GO or NO-GO, and the first one caught 2 critical regressions before main.
Model by risk
A stronger model for money, auth, native code and architecture. A lighter one for 1:1 ports and simple screens.
Gates
Database migrations, merges to main, redeploys of production workers and store builds were out of reach for agents alone: they prepared them, and a human approved, sometimes for a whole wave.

07 / Decisions and trade-offs

What stayed out, on purpose.

  1. 7.1
    Not used

    No RAG in the MVP.

    The knowledge base has 58 curated entries, each approved before it goes live, and keyword search. The decision defines when to revisit it: only if the corpus exceeds 200 KB of useful text, "I don’t know" answers due to missing context exceed 10% for two weeks in a row, and someone owns the curation.

  2. 7.2

    No tool touches money.

    The tools look up data, write internal notes and hand the conversation off to a human, with an allowlist and auditing. A tool for money, sign-up or cancellation does not exist.

  3. 7.3

    A new app, not a patch on Flutter.

    The GCP exit discovery showed that the biggest coupling was in the client: the Flutter app talked to Firebase straight through the SDK. For its data, the new app talks only to in-house Workers, and the Flutter app stays in the stores until the swap.

  4. 7.4

    Accounts in Postgres, Firebase Auth only on the first login.

    In the new app, an account is the row in Postgres. On the first login, the auth Worker checks the password with Firebase once and saves its own hash. After that, it never asks Firebase again for that account, and it never writes to Firebase.

  5. 7.5

    Strangler‑fig, not big bang.

    Migrated routes went through service bindings behind the gateway, and routes not migrated kept running on the functions. Only the compute moved: Firestore and Realtime Database stayed on GCP, because the limit was the vCPU quota.

  6. 7.6

    Money, isolated.

    An isolated payments service, a double-entry ledger with no public route, and webhooks whose authenticity is checked (HMAC when the provider signs).

08 / Result

Agent live. New app on the way.

The new app’s first production builds came out in Oct 2026, and it is set up to replace the Flutter app as an update in the stores. The new admin app already runs on the web, on production data.

  • AIIn productionAgent in real conversations, with a person reviewing every reply.
  • AppPre-launchExpo app built with coding agents.