EasyFix: a three-sided marketplace for car repairs

What it is

EasyFix was a three-sided marketplace for car repairs in São Paulo, Brazil:

A car owner with a problem requested help through the app
A FIXER — a mobile mechanic-diagnostician with a smartphone toolkit — would arrive, diagnose the car, and post the diagnosis to the platform
Nearby garages then bid in a real-time auction to perform the repair
The customer chose the offer they liked best

The model fixed a real problem: in Brazil, car owners don’t trust mechanics, and mechanics don’t have an easy way to advertise. Putting an independent diagnostician in the middle, plus an auction for the actual repair work, removed both points of friction at once.

The team

Four co-founders, equal partners (25% each), each from a very different background:

Wilson — CEO. Drove the business, partnerships, and go-to-market.
Diego — COO. Decades of hands-on car-repair expertise; he was the soul of the FIXER role and shaped how diagnoses and quotes actually worked in the wild.
Fabio — Frontend lead. Built the consumer Android app and the FIXER mobile app.
Geovane (me) — CTO. Designed and built the backend; ran the technical organization.

It was a really good team. We worked nights and weekends around our day jobs — a businessman, a master mechanic, a frontend developer, and a backend engineer — genuinely figuring it out together.

What I built

As CTO (Jan 2017 → Jan 2018), I designed and built the backend and led the technical organization:

Backend in Elixir + Phoenix with PostgreSQL, serving three different clients: the consumer Android app, the FIXER mobile app, and the garage web/desktop app
A domain model spanning users, vehicles, a hierarchical parts catalog (systems → groups → sub-groups → parts), diagnoses, quotes, orders with a state machine, and end-to-end payments (bank accounts, payment parts, reconciliation)
Three user roles, each with a distinct flow: customer (request + approve), FIXER (diagnose, points-based incentives), garage (quote, fulfill, get rated)
The auction logic for repair quotes — first iteration of the bidding round
Separated administrative and operational schemas for analytics + KPIs
Stack decisions, repo layout, and engineering practices for the team

Why it was hard

Three-sided marketplace on a thin team — every feature touches three different apps with three different incentive structures
Long-tail catalog — tens of thousands of car parts. The data model had to be flexible enough to capture anything a FIXER might diagnose, and structured enough to drive an auction
Trust in a low-trust market — the FIXER role was designed precisely to bridge customer/garage trust, but it needed reputation, mutual ratings, and dispute handling built into the platform
Brazilian payment realities — local banks, manual reconciliation, no clean Stripe-equivalent at the time. We built our own payment data model
Bootstrapped — no investors, all four co-founders working part-time around day jobs

Numbers

300+ users during my tenure
4 co-founders, each with 25% equity
~30 production tables — users, vehicles, diagnoses, garages, quotes, orders, payments, parts catalog, geography, coupons
3 client apps (consumer Android, FIXER mobile, garage web)
Active from early 2017; I led tech through January 2018; the database ran in production until at least February 2019

Why I’m proud of it

This was my first time leading a technical organization end-to-end — choosing the stack, setting team practices, and shipping a working three-sided marketplace from zero. The Elixir/Phoenix bet held up: small team, lots of moving parts, the system kept up. The product taught me that most of a startup is operations, design, and trust — not just code.