Vamos Juntos

The problem

What we built

1. 01

   Matching on geography, with searches that outlive the query

   Route matching runs as dedicated geo services rather than as database predicates, and a search that finds nothing today is saved — so the user is notified when a matching ride is posted later. It turns an empty result into a pending one.

   • Dedicated geo and geocoding services behind the API
   • Saved ride searches that fire a notification on a later match
   • Map-first interface on the client, not a form with two text inputs
2. 02

   Identity verified once, at the edge

   Firebase issues the token, and an API Gateway JWT authorizer validates it before any function runs. No handler hand-rolls token parsing, which is exactly where auth bugs come from when there are thirty of them.

   • Firebase JWT authorizer configured at the HTTP API layer
   • Sign-in with Google and Apple, plus phone-based registration
   • Handlers receive an already-authenticated identity
3. 03

   A serverless API sized per function

   The API is a set of independently packaged Lambda functions deployed with the Serverless Framework to São Paulo — the closest AWS region to Uruguay, which matters more than it sounds when the client is on mobile data on a highway.

   • Each function packaged and optimised individually, so cold starts stay small
   • TypeScript end to end, with the entity and repository layers shared
   • Deployed to sa-east-1 for Latin American latency
4. 04

   The full ride lifecycle, including when it goes wrong

   Rides, ride requests, passengers, reviews and complaints are each modelled explicitly. The complaint path is not an afterthought bolted on after the first bad trip — it shipped with the product.

   • Request and accept flow with seat accounting
   • Reviews in both directions, driver and passenger
   • A complaint path with its own handling, separate from reviews
5. 05

   Realtime messaging with shared location

   Once a ride is agreed, riders and drivers coordinate in-app. Messaging runs on Firestore with push through Firebase Cloud Messaging, so the conversation survives the app being backgrounded — which it always is, because the user is travelling.

   • Firestore-backed messaging with live location sharing
   • Push notifications through Firebase Cloud Messaging
   • Crashlytics, Analytics and Remote Config for release safety
6. 06

   Two client generations

   The product shipped first as a React Native app in TypeScript, then was rebuilt in Flutter as the team's needs changed. Both generations ran against the same API — which is the payoff for having drawn that boundary properly in the first place.

   • v1: React Native, Redux Toolkit, React Navigation, native maps
   • v2: Flutter with Riverpod and a GraphQL client
   • One API contract across both, no rewrite of the backend

The stack