Case study
BikerWay
A map, convoy and club platform for motorcyclists, with AI pipelines that keep its catalogue of routes and places alive.
- Role
- Founder & lead engineer, with a small team
- Since
- 2026
- Status
- Beta Android beta · iOS later

01 / Problem
Generic maps don't answer a rider's questions.
Riders in Brazil plan trips around questions generic map apps don't answer well: which fuel stations, workshops and places to stay can be trusted, and which roads are worth riding on a motorcycle. Clubs and group rides run on scattered chat groups. No single product brought the map and the community together.
The goal is something like PlugShare for motorcyclists: a shared map that the community confirms, corrects and extends, where a new rider sees useful routes and places on the first day.
02 / Product
A rider's map, a convoy radar and a club platform.
Live convoys
Group rides on a live map. A native background-location task keeps the convoy visible while phones sit in pockets.
Routes & trusted places
Recommended routes, rider-relevant places (fuel, workshops, viewpoints), reviews and a community consensus on fuel prices.
Clubs
Motorcycle clubs with rankings, territories, recruitment and check-ins.
Events & invites
Events and club meetups, shareable invite links that open the app or fall back to a download page.
Garage
A virtual garage with fuel consumption, expenses and maintenance history per motorcycle.
Ride journal
A log of past rides with distance, duration, number of motorcycles and photos.
SOS alerts with live location exist in the web app; in the native app they are planned for after the beta.


03 / Architecture
Five repositories, one database, explicit contracts.
- Production
- Runs against real users or production data
- Beta
- Live with real testers, not publicly released yet
- In use
- Internal tooling I actively use
- Experimental
- Built and tested, not operated regularly yet
- Planned
- Designed and on the board, not built
Architecture of BikerWay in four layers. Select a component for details.
Clients
Platform
AI & data
Operations
Native app
BetaExpo · React Native · TypeScript · Tamagui · TanStack Query
The main product. Android first: background location for convoys, native push and maps. iOS comes after the beta.
04 / Engineering decisions
The calls that shaped the system.
- 01
Many repos, one schema owner
Five repositories with different deploy targets share one Supabase project. When schema drift between repos caused production bugs, I added a context repository holding the architecture, a cross-project change checklist and the roadmap, plus generated types synced to every consumer.
- 02
Convoys that survive a locked screen
Foreground presence alone loses riders whose phone is in a pocket. A native background-location task writes to an RLS-protected table with realtime updates, and the feature only counted as done after a two-device field test.
- 03
Rules live in the database
Row-level security as the default, per-user rate limits on user content enforced by triggers, and notifications fired by triggers. Every client, including code written by agents, gets the same guarantees.
- 04
AI proposes, rules decide, humans curate
Pipelines never write directly to content tables. One ingestion layer validates, normalizes, deduplicates, scores confidence from evidence and decides whether a record is published or queued for review.
- 05
Licence-aware data
Map-provider terms limit what can be stored and for how long. The pipelines keep only what the terms allow, refresh or replace coordinates before they expire, and use OpenStreetMap, with attribution, as the long-term source.
- 06
A budget is an architecture constraint
New spending has a fixed monthly ceiling until the product earns revenue. That shaped the stack: free tiers first, AI budgets that fail closed, and web search capped at free quotas with no paid fallback.
05 / AI architecture
Where AI runs today, and where it's going.
Route & place discovery pipelines
ProductionAn LLM proposes candidates, real map data enriches them, and a confidence gate plus the ingestion layer decide what gets published.
Single ingestion layer
ProductionDeduplication by place ID, proximity and name similarity; evidence stored per record; publication status decided by rules, not by the model.
Agent development team
In use14 Claude Code agents with a consensus protocol and human-only risk gates.
AI marketing engine
ExperimentalTrend discovery, copy and image generation with Telegram approval. Publishing is still manual.
AI runtime with cost control
ExperimentalPluggable LLM providers (including DeepSeek), token cost recorded per call, monthly budgets that fail closed.
Content agent team (AG-0…AG-7)
PlannedEditor-in-chief, places, events, famous routes, composed routes, challenges & badges, parts & manuals, offers, and a verifier, behind an MCP server and a curation queue.
The agent team and its protocol are described in AI workforce.
06 / Why it matters
What this project shows about how I work.
- Product thinking
- A clear problem, a PlugShare-style vision, and a roadmap ordered by cost and traction.
- Architecture
- Five repos, one schema owner, contracts kept in sync through a shared context repo.
- AI systems
- LLMs inside a pipeline with schemas, confidence scoring, evidence and approval gates.
- Automation
- An agent team that refines and builds stories, with humans holding the irreversible steps.
- Cloud & backend
- Postgres with RLS, Edge Functions, Vault secrets, triggers and realtime channels.
- Mobile
- A native app with background location and push, tested on physical devices.
- Data
- Provenance, deduplication and licence-aware storage of map data.
- Experimentation
- PostHog on web and mobile, and roadmap waves ordered to validate traction before spending more.