This is the first in an occasional series we're calling Decision Room — real sequencing and scope decisions from projects we've built, with enough detail to be useful and enough restraint to respect the privacy we agreed to. Client and founder identity are withheld by request. The product name, Liftly, and the shape of the V1/V2 decision are shared with permission.
The situation
Liftly's founder had a genuine, well-thought-out vision: a logistics and service booking marketplace with a sophisticated, variable pricing engine at its core — service minimums, distance bands, labor and movers, stairs, urgency, specialty and heavy items, margin protection. That pricing engine was meant to be the product's real differentiator.
The problem wasn't the vision. It was the order. Building the full pricing complexity first would have delayed launching the thing the business actually needed to prove before anything else: can a customer book a job, can the business see and manage it, and can payment happen reliably. A sophisticated pricing engine has nothing real to price until that loop works.
What we built — V1
We separated the vision from the first release. V1 shipped as a complete, usable operational foundation on its own:
- Customer booking, pickup/dropoff, and job/item detail capture
- Serviceability and distance-based eligibility logic
- Booking deposits and payment handling
- Internal admin and booking operations controls, for running bookings day to day
None of this is a stripped-down placeholder. It's the real operational loop a booking business needs to run — just without the variable-pricing sophistication layered on top yet.
What we designed, but did not build — V2
This part is important to be precise about: the Pricing Engine V2 was documented and scoped during V1, but it was not built. It has not shipped. The concepts that exist today as design, not code, include service minimums, distance bands, labor and movers pricing, stairs, urgency multipliers, specialty and heavy item handling, junk-removal load estimation, disposal estimates, admin overrides, customer approval flows, and margin protection.
Designing V2 during V1 — instead of leaving it as a vague future idea — means the next phase starts from a real foundation instead of a blank page. But it's still a plan, not a product, and we're not going to describe it as anything more than that.
The actual reasoning
Two decisions did the real work here, and neither was about the code:
Ship the operational loop before the pricing sophistication. The business needed proof that bookings, serviceability, and payment worked end to end before a variable pricing engine had anything real to price against. Building pricing complexity against an unproven booking flow risks building the wrong thing well.
Design V2 deliberately instead of bolting it on later. Rather than treating the pricing engine as "whatever we figure out eventually," the concepts were scoped and documented alongside V1, so the sequencing decision doesn't cost the vision — it just orders it.
Why this is worth reading if you're not building a booking platform
The specifics are Liftly's. The pattern isn't. Founders with a genuinely bigger vision than their first release can carry face this exact fork constantly: build the sophisticated version of the idea first, or prove the operational core and sequence the sophistication deliberately. The second path is usually less exciting to describe in a pitch and more likely to produce something real. It's the same instinct behind proving the problem before the clock starts on any new build.
Where this stands today
V1 is built and operational. Pricing Engine V2 remains designed, not built — that's a factual status, not a hedge. The full case study has more detail on the engagement, kept within the same privacy boundaries as this piece.