An on-demand local services marketplace, rescued under NDA
This aggregator connects people who need quick local services with providers close by. A customer submits a request, the platform matches it with nearby providers, and the job is booked and paid for online. We joined when the project was badly behind schedule. The client is under NDA, so this case study covers the situation, the decisions and what shipped, without names.
The situation: eight months of scope, one month of runway
An honest estimate for the remaining work came to about eight months. The business had roughly one, and every extra month cost cash and investor patience. That left two options. The team could build everything as planned and risk the company not surviving to launch, or ship what launch required, on time. We chose the second option deliberately, as an engineering decision.
How we delivered the MVP in about a month
1. A hard technical triage
We started with an audit of the existing codebase: what worked, what could be salvaged and what would be faster to rewrite. Part of what we inherited ran on legacy PHP 5.6. We didn't attempt a wholesale rewrite. Instead we decided exactly what had to change before launch and left working legacy parts alone until after it.
2. Ruthless scope prioritization
The most important decision was also the least popular: cut the scope to what the first launch truly needed. Everything else went to a post-release backlog. What remained was the core of a services marketplace, the flows without which no customer could get a job done.
3. Parallel work on separated modules
Even the trimmed scope was far too much for one person in a month. We split the system into clearly separated modules and ran the work in parallel across six full-stack developers, so nobody was waiting on anyone else. The team lead's job wasn't to write the most code. It was to hold the critical path: unblocking developers, integrating modules, making sure the pieces fit and keeping scope creep away from the team.
Key features shipped at launch
- Geo-based provider matching: built on the Yandex Maps API, so a request reaches providers who are actually nearby.
- Booking and online payment: customers book a provider and pay through an online payments integration.
- Provider onboarding: service providers are onboarded through the admin panel.
- Dispute handling: tools for resolving disputes between customers and providers.
- Request lifecycle webhooks: events fire as a request moves through its lifecycle, feeding integrations and notifications.
Architecture and tech stack
The backend runs on Laravel 8 with MariaDB, alongside the legacy PHP 5.6 code we chose to keep for launch. The frontend is Vue.js 2, bundled with Laravel Mix. Location logic for matching runs on the Yandex Maps API.
Lifecycle webhooks keep side effects such as notifications out of the core booking code. The marketplace emits an event whenever a request changes state, and anything that needs to react subscribes to it. That boundary also made the parallel workflow possible, because code that reacts to a request doesn't have to change the code that manages it.
Outcome
The MVP went live in roughly one month instead of eight, with matching, booking, payments, onboarding and disputes all working. With the core flows in place, the client could get back to acquiring users and onboarding providers.
What this project shows
- The deadline is part of the product. A complete product that arrives after the business runs out of money helps no one.
- Deciding what not to build saves more time than overtime. Cutting features did more for the schedule than any extra hours could have.
- Parallel teams need architecture. Six developers only speed things up when the modules keep them from colliding.
Related work
Rescuing a project that is stuck behind schedule is part of our web app development work. For marketplaces we built as our own products, see Bronjoy, an appointment booking marketplace, and Bazarmap, a multi-sided marketplace with separate customer, seller and manager apps.
