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 protect the client's identity. Client and founder identity are withheld. Every fact below comes from the project record, and where the record is silent, this piece says so.
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.
Here is the fork, before we say what we chose. Build the pricing engine first, so the differentiator exists from day one? Or build the operational loop around it first, and design the engine for later? Either can be defended. What would you want to know before choosing?
What we built — V1
We chose the loop. We separated the vision from the first release, and 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
The problem wasn't the vision. It was the order. Building the full pricing complexity first would have delayed launching the thing the business 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.
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.
What would justify building V2
We can't tell you whether the pricing engine has been justified. The record shows V1 built and V2 designed. It contains no post-launch usage data, and we're not going to invent any. What would justify building it is evidence from real use of the operational loop: bookings completing end to end, and a specific place where the missing pricing capability is what's limiting the business. Until then, Pricing Engine V2 stays where the record puts 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 fork: build the sophisticated version of the idea first, or prove the operational core and sequence the sophistication deliberately. In our view the second path is less exciting to describe in a pitch and more likely to produce something real. It's the same instinct behind deciding what a first version has to prove before the clock starts, which that article works through.
Where this stands today
- Built: the V1 operational core.
- Designed, not built: Pricing Engine V2. That is a factual status, not a hedge.
- Not yet justified: building V2. The evidence above isn't in the record.
The full case study has more detail on the engagement, within the same boundaries as this piece.