AI first, quality first

Four applications built with AI as a pair from day one. Not to go faster, though it did: to hold the bar on interface, patterns and code that is safe to maintain. AI as the quality gate, not only the accelerator.

Role: co-founder. Product, design and full-stack development.
Partner: Raphael Capeto, on platform architecture.
Product: HUAH, a platform that turns time stuck in traffic into points you can redeem with partners. Four applications: the mobile app, the API, the backoffice and the partner portal.
Period: three months from concept to an app ready for the store: good UI, patterns, secure code that is easy to maintain.
Status: ready for the stores, starting with São Paulo. No traction numbers yet.

Three jumps

The idea, in a quick prototype. One of the partners brought the concept as a Replit prototype, enough for it to stop being a conversation and become something clickable.

The interface, without code. I built the second prototype in Claude Design, back when the tool was still in closed testing. That was on purpose, because I wanted to settle the UI and a few experience decisions at the speed of someone thinking only about interface. The prototype was thrown away, and the decisions stayed.

The product, straight into code. The prototype moved to Claude Code and became the real repository, one monorepo with four applications. From there on, evolving the experience and evolving the product became the same gesture.

A line that thickens across three stages. First, a quick prototype that validates the idea, disposable. Second, a UI prototype built in Claude Design, also disposable, which validates the interface without spending energy on code. Third, production: a single repository with four applications, permanent. The highlighted point marks where the prototype becomes the repository, after which evolving the experience and evolving the product are the same gesture. — DIAGRAM · THREE JUMPS FROM IDEA TO PRODUCT

Two decisions

The app never asks for location before login. The permission provider only lets the request happen once the person is authenticated, so the first thing a newcomer sees is not a system prompt. On the Home, the GPS banner is where the person asks to start earning, and it stays off until they do.

The second decision lives in Directions. If GPS or Motion is off when someone asks the way to a partner, the sheet says so before they leave. This trip will not earn points, but we still mark your destination. That is expectation management inside the flow, not on a FAQ page. During the trip the earn gate zeroes the gain if a sensor is missing, so warning and rule agree.

The HUAH Home with GPS off: a banner at the top reads GPS disabled, zero points per minute, with the button Turn on GPS now; the card Where are you going is disabled below it. — SCREENS · IOS SIMULATOR, FIXTURE DATA

The partner screen for a café with the Directions sheet open. Above the options Waze, Google Maps, Apple Maps and open in browser, a line warns: without GPS and Motion on, this trip will not earn points, but we keep marking your destination. — SCREENS · IOS SIMULATOR, FIXTURE DATA

From a trip to a redemption

The experience does not end in the app. The points a trip earns are recomputed on the server, never trusted from the phone, and anti-fraud sends suspicious sessions to a review queue where an admin confirms or reverses them in the backoffice. A coupon is redeemed with a six-character code the shop validates in the partner portal, and no points move at validation. Deciding that contract counts as design work.

Twelve steps in two rows across the four applications. A trip becomes points: login, and only after it is GPS asked; GPS and Motion requested on the Home; in Directions, without a sensor the app warns the trip will not earn and still marks the destination; the engine detects the trip and uploads the segment; the API recomputes and credits the points, sending suspicious cases to review; an admin confirms or reverses in the backoffice. Points become a coupon: the driver picks a coupon with an approved licence; the API debits and issues a six-character code; the app shows it with a countdown; the shop validates it in the partner portal; the API marks it accepted without moving points; the backoffice audits. — DIAGRAM · FROM A TRIP TO A REDEMPTION, ACROSS THE FOUR APPLICATIONS

Who did what

Antonio: 15 ADRs alone; The foundations: the monorepo, the backend, Postgres, Firebase Auth, the points ledger. Most of my commits are in the mobile app, where the experience decisions live.
Raphael: 15 ADRs alone; The feature slices: driver identity, redemption, licence verification, the counter validator mode, hosting. He is the largest committer in every one of the four applications.
Together: 11 ADRs; The decisions signed by both, out of 41 architecture decision records in the repository.

The discipline came along from day one. Schema-validated design tokens, the 41 decision records, CI, periodic drift audits between documentation and code, and development governed by missions with gates. Not as a designer who comments on the front end, but as a partner who builds, with AI as a pair.

Limits and learning

No traction numbers, because the product is not in the stores yet. What was validated so far was validated between the partners, on prototypes and on the app itself. There is no user test to report, and I would rather say that than dress it up.

The driving state could not be captured: in the simulator the Motion permission never resolves, and there is no UI override. And the redemption code is still text, not a QR code. Both are on the list.