Hospitality
A seemingly simple question about an in-house online ordering and delivery channel grew into a product discovery project. Before anything was built or chosen, Simply Dom researched the desired customer experience, existing solutions, possible architectures and the operational consequences — including the reasons why several obvious routes were ruled out.
The situation
The question came straight from practice. A hospitality business owner wanted more control over their own online ordering and delivery channel, with their own drivers, without giving up a customer experience that large platforms have since made the norm.
One element was particularly concrete: the customer had to be able to genuinely track their order during delivery. Not a status saying "on its way," not just an estimated delivery time, but seeing where the delivery actually was.
At first glance, a software question: which solution offers this? Early research quickly made clear that framing was too simple.
The business question
Plenty of systems exist for online ordering, and just as many for dispatch, routes and drivers. Strikingly many vendors use words like "live tracking" or "real-time delivery." Except those words don't mean the same thing everywhere.
Sometimes the owner can track their drivers live, but the customer can't. Sometimes the customer gets status updates with no map. Sometimes the desired experience only exists when an external courier partner handles the delivery. And sometimes a platform offers almost everything needed — except exactly the one piece the research had started with.
So the difficulty wasn't finding vendors; there were plenty of those. The difficulty was demonstrating which combination could actually deliver the requested experience, with in-house drivers, a workable daily operation, and enough control over the customer channel.
The choices made
The first step was defining the desired experience precisely. "Live tracking" wasn't accepted as a feature label; the question got more concrete: does the end customer need to see a moving driver position on a map while the order is en route? That became the test.
Next, the layers of the problem were pulled apart. On one side, the commercial customer channel: assortment, ordering, payment, customer data and communication. On the other, execution: assigning orders, directing drivers, routes, status and location.
That split made different architectures visible: a single platform doing everything, an ordering platform paired with specialised last-mile software, an existing solution combined with an external delivery partner, or more custom work around systems that each separately already offer proven components.
Not every route got equal time. When a core requirement couldn't be demonstrably supported, it was ruled out. That mattered more than producing a long shortlist.
My role
My role was product discovery and opportunity validation: breaking the original request apart, writing out the desired customer experience, researching existing ordering platforms and last-mile solutions separately, and checking what vendors actually mean when they write "live tracking."
Throughout, it was explicitly recorded what had been demonstrated, what was only a marketing claim, and what remained an open question.
The operational and commercial side was factored in too. What does the end customer see, what does the driver see, what does the owner need to be able to do? How does an order get from one system to another, and where does an extra manual step creep in? Who owns the customer relationship? And how much dependency genuinely shifts when you replace one marketplace with several software vendors?
Whether the benefit is big enough to justify that added complexity was deliberately left open: that question can only be seriously answered once it's clear which architecture can even do what's being asked.
The research was then challenged again — not to keep as many solutions as possible, but to rule out, faster, the ones that on closer inspection didn't do what they'd seemed to do at first glance.
Execution
The result of that first discovery phase wasn't software, and it wasn't meant to be. What existed instead was a much sharper picture of the problem: a written-out customer flow, a separate flow for the driver and operational control, a comparison of possible platform categories, and an overview of solutions ruled out on essential points — with the reason why.
Alongside that sat an initial architecture picture of which systems might work together, and above all a list of questions that still needed proving in a next round of research.
That also clarified where further research was actually worth doing: not re-contacting twenty vendors, but testing a limited set of routes specifically against the conditions that genuinely mattered. Only after that can technical feasibility, operational workability and economics be judged together.
Status update — August 2026
The second round of research has mainly narrowed the field.
There's no shortage of platforms for online ordering, dispatch, and driver support. What's less consistent is what “live tracking” actually means. With some solutions, the operator can follow their drivers but the customer can't. Elsewhere the customer gets status updates without seeing a map. And in some models, that experience only exists when an external courier partner handles the delivery. Those routes have fallen away.
At the same time, the operational question sharpened. Multiple hospitality brands need to be able to operate through their own direct channel, sharing one team of in-house drivers. Orders need to land correctly, drivers need to be dispatchable, and the customer needs the same clarity during delivery that they're used to from major platforms.
The comparison leaves one concrete route standing: a direct ordering platform combined with dispatch and driver functionality. On paper, that combination comes closest to what's being sought. But the element the assignment started with is still unproven: during a delivery with in-house drivers, can the end customer actually watch their driver's position move on a map?
It also still has to become clear how multiple brands are handled within the same operation, what the daily workflow looks like in practice, what licensing is needed, and what it all costs.
The next step therefore stays deliberately small: a demo of the real system, confirmation of that critical flow, and a concrete quote. No implementation, no custom work, no business case built on marketing claims. Only once those pieces are on the table can it be judged whether this holds up technically and operationally, and whether it's financially sound.
The case isn't finished yet. But what still needs proving is now precisely defined.
What was deliberately not done
No "yes, that's possible" just because a website mentioned "live tracking" somewhere. No platform recommended without checking who could actually see that tracking. No custom build proposed just because existing solutions weren't an immediate perfect fit. No software stack chosen before it was clear how it would need to be used day to day. And no business case built around features that hadn't been demonstrated yet.
At this stage, nothing needed to be sold yet.
The first gain was already there: less uncertainty.
Some options fell away as a result, others became more interesting, and the original question became far sharper than it was at the start.
That's exactly what product discovery is supposed to do.