Building FixMasters: Lessons from a Two-Sided Marketplace
Building an app that connects users with handymen taught me more about product design than any tutorial. Here's what I learned.
FixMasters started as a straightforward idea: connect users to local handymen. The execution turned out to be anything but straightforward.
Two Users, Two Apps in One
The hardest part of building a two-sided marketplace isn't the code — it's designing for two completely different user types in the same product. Users want simplicity: find someone, book them, done. Handymen want control: manage their gigs, set availability, track bookings.
I ended up building effectively two apps that share a backend — a user-facing app and a handyman dashboard. Keeping the UX coherent across both while serving different mental models was the biggest design challenge I've faced.

Firebase Was the Right Backend Call
For the scope of FixMasters, Firebase was the right choice. Firestore's real-time listeners made the chat feature straightforward to build — messages appear instantly without polling. Firebase Auth handled the multi-role user system cleanly.
The tradeoff is cost predictability at scale. Firestore's read-based pricing can get expensive fast with a busy chat feature. For a larger production app, I'd evaluate a PostgreSQL backend more seriously.
Real-Time Chat Is Deceptively Hard
Chat looks simple from the outside. Under the hood, you're dealing with message ordering, delivery receipts, push notifications, and offline queuing. The Convo project I built separately helped me understand these patterns before I had to implement them in FixMasters.
The key insight: model messages as immutable events, not mutable records. Append-only data structures make conflict resolution trivial.
Location Matching Without Maps
The "nearest handyman" feature doesn't actually use a map UI — it's a background calculation comparing geohashes stored in Firestore. Geohash-based proximity queries are a clever trick that lets you find nearby documents without a dedicated geospatial database. The Mapbox experience from Debbol informed this approach.
What I'd Do Differently
I'd invest more in onboarding for handymen. Getting supply-side users to complete their profile, add their services, and stay engaged is harder than getting demand-side users to place a booking. Onboarding friction kills marketplaces.