Two-sided marketplace for local services, built from zero
A startup connecting residents with verified local service providers had the product idea but none of the technical foundation: no API, database, authentication, payments or dashboards. One engineer had to build all of it.
- My role
- Tech Lead - fullstack development, infrastructure and business analysis
- Team
- 4 - Product manager, UI/UX designer, digital marketer, engineer
- Timeline
- 4 months to production
- Constraint
- A two-sided marketplace with payments, booking and disputes, built while the business model was still being validated
The problem
In a two-sided marketplace every system depends on another. Booking needs authentication, payments need a verified provider and disputes need a complete booking history, so the data model has to account for all of it from the start.
The business model was also still being validated, so requirements changed as decisions were made. The system had to be reliable enough to trust and flexible enough to absorb those changes without rebuilding core logic.
The tradeoff I made
I designed the booking and payment flows as explicit state machines instead of status fields scattered across the database. Every step a booking could go through was a defined state with defined rules for what could follow it. This took more design up front, but when requirements changed we updated the rules in one place instead of hunting through API handlers, and every booking's full history could always be reconstructed.
Explicit state over flexible fields: the business rules were too important to leave implicit.
Outcomes
Production dashboards - customer, service provider and admin - each with role-specific flows and access control
Separate environments, development and production, with deployment pipelines, logging and monitoring in place
Complete platform delivered - API, database, authentication, payments, booking, disputes, public pages and SEO - from zero to production
What I would do differently
I would agree a written API contract with the product manager before writing any code. Changing requirements are normal in a startup, but some late changes touched API responses the frontend already depended on. Even a simple versioned API spec agreed up front would have kept those changes inside the backend and forced some business decisions earlier.