Wastes — Case Study

Two-sided marketplace for construction-waste haulage, covering mobile apps for clients and drivers, a web back-office, and an internal BI stack.

Summary

The product is an "Uber for construction waste removal" — construction sites place haulage orders; independent drivers and haulage companies accept and fulfill them. topsweteam handled the full build: several rounds of product design, business analytics alongside the client's operations team, two mobile apps (client and driver), a web back-office, and an internal BI stack. A team of ten took the system from concept to production.

• Client: rfc-eco
• Industry: Logistics / Construction tech
• Engagement: Full build-out (design → analytics → engineering → BI)
• Timeline: 2021–2022 (~12 months)
• Team: ~10 people across design, analytics, engineering
• Status: Shipped to production; subsequently wound down by the client

Challenge

Construction-waste haulage is a fragmented market: brokers, independent drivers, small haulage companies, and dozens of waste-type and site-location edge cases. The client wanted to compress the brokering workflow into a marketplace where sites could place an order in minutes and drivers could see and accept jobs in real time. Three things had to be true at once: the UX had to work for site foremen on a phone at a dusty site, drivers had to have a separate app tuned to their workflow, and the back-office had to give operations enough visibility to debug any order in the pipeline.

Approach

We structured the engagement around the two-sided nature of the marketplace. Design went through several iterations in parallel for the client and driver apps — the flows look similar, but the assumptions behind them are very different, and an early bias we had to unlearn was that "a driver app is the same thing as a client app with different copy". Business analytics was done jointly with the client's operations team so that the data model and the ops workflow matched from day one rather than having to be reconciled after launch.

• Node.js + NestJS for the backend. Deliberate choice over a JVM stack: the domain is I/O-heavy (lots of order-state transitions, real-time driver updates, integrations) and the team was already fluent in TypeScript end to end.
• AdminJS for the back-office. Faster to build than a custom web admin and good enough for operational CRUD; we kept customer-facing surfaces custom.
• React Native + Expo for both apps. One codebase pattern, two products. The Expo managed workflow traded a little native flexibility for a lot of release-cycle speed.

Solution

The platform runs on Yandex.Cloud with PostgreSQL as the system of record. The backend is a NestJS monorepo; AdminJS sits on top of it for the operations team. Two React Native apps — client and driver — share a common data layer but have independent navigation, permissions, and flows. A web app covers customer use cases that don't fit a phone. An internal BI layer pulls from the same Postgres and gives ops and the client's leadership reporting on order volume, SLA, and driver utilization.

Architecture

One Node.js/NestJS backend serves four surfaces: client mobile, driver mobile, web app, and the AdminJS back-office. Real-time order state and driver position updates use WebSockets; everything else is REST. Postgres is the single source of truth. BI reporting runs off the same database with dedicated read queries.

Key features shipped

• Client mobile app: place order, pick waste type and volume, track pickup
• Driver mobile app: see jobs nearby, accept, route to site, close out the order
• Web app for clients who prefer desktop workflows
• AdminJS back-office: order management, user management, dispute handling
• BI stack: order volume, SLA compliance, driver utilization, revenue reporting

Outcome

The full system — two apps, web, admin, BI — shipped to production over a 12-month engagement in 2021–2022. A 10-person engagement handled design, business analytics, and implementation without a separate systems-integrator on top. Operations ran the day-to-day from AdminJS; leadership used the BI stack for weekly reporting. The product was subsequently wound down by the client for non-engineering reasons.

• Two mobile apps plus web and back-office shipped in 12 months
• Internal BI stack live from launch, not bolted on later
• 10-person cross-functional team delivered design, analytics, and engineering end-to-end

Tech stack

Infrastructure: PostgreSQL, Docker, Yandex.Cloud Backend: Node.js, NestJS, AdminJS, PostgreSQL Web: React, MobX Mobile: React Native, Expo Data: Internal BI layer on PostgreSQL

What we learned

• "Same app, different user" is a trap on two-sided marketplaces. The client and driver apps looked 70% similar in Figma and turned out to be 30% similar in code.
• Running business analytics jointly with the client's operations team avoided a post-launch reconciliation that we'd seen go badly on other projects.
• AdminJS bought 2–3 months of delivery time compared to a custom back-office, with no material user-experience loss for the internal team.