Building the Technology Layer for Australia's Dark Kitchen Revolution
Industry
Retail & Hospitality
Company size
1 - 10 Employees
About
Bellee is a Sydney-based food delivery platform and "ghost kitchen" network that helps local restaurants expand their reach and reduce overhead costs. Operating primarily in suburbs like Kogarah, it provides commercial kitchen spaces and a dedicated delivery team.
"Halcrow helped us navigate partner access with the platforms, which was the real bottleneck. The result was a technology layer that turned fragmented platform data into operational intelligence we can actually run the business on."
All orders
(KMR): Centralised data visibility across all kitchens and delivery platforms, with a dashboard that turned fragmented delivery platform data into Bellee's proprietary operational intelligence.
We've been inside enough initiatives to know where the value actually is and where businesses waste on technology.
Book Your Diagnostic Call
The Situation
Our client is a construction manager. He had an empty block next to his office in a high-demand Sydney suburb, and a clear-eyed read on a structural shift in the food industry: restaurant operators didn't need dining rooms. They needed commercial kitchens in locations that got them onto Uber Eats, Menulog, and DoorDash in the suburbs where the orders were.
He built 20 dark kitchens. Rented them to hospitality operators who couldn't afford their own premises. The physical business worked. Operators moved in. Orders started flowing.
The problem: 20 separate businesses, each operating through three delivery platforms, with our client owning the physical infrastructure and no visibility into any of it.
From a unit economics perspective, Bellee's competitive advantage wasn't just the kitchen space — it was the location, the equipment, and the operational support. But "operational support" meant nothing if our client couldn't see which kitchens were performing, which operators were thriving, which shifts were peaking, and where the money was going.
What our client needed technically:
A way to connect all 20 kitchens' orders — across Uber Eats, Menulog, and DoorDash — into a single data layer that Bellee owned
A dashboard showing kitchen performance across the portfolio: orders, revenue, utilisation, peak times
A technology interface that gave operators access to their own performance data, supporting retention and renewal conversations
The infrastructure to become a technology-first dark kitchen operator, not just a landlord Key Result Metric
(KMR): Centralised data visibility across all kitchens and delivery platforms, with a dashboard that turned fragmented delivery platform data into Bellee's proprietary operational intelligence.
Why they called us
Our client didn't come to Halcrow with a technology brief.
He came with a business problem: I own the real estate and the equipment, but the three delivery platforms own all the data about how my kitchens are performing.
He'd looked at off-the-shelf solutions. Point-of-sale integrations, kitchen management software, aggregator platforms. None of them were designed for the specific model Bellee operated: a facilitator, not a direct merchant. Bellee's operators were the merchants. Bellee was the infrastructure provider. This mattered technically.
The specific constraint: Uber Eats, Menulog, and DoorDash each required the integrating party to be a registered merchant. Bellee wasn't a merchant — it was a facilitator of merchants. Getting API access required navigating a problem that was never purely technical: it required Bellee to be categorised correctly in each platform's partnership program, which required conversations directly with Uber, Menulog, and DoorDash integration teams.
This is the integration challenge that most technology projects encounter and underestimate. The technology is never the hard part. The access, the people, and the processes around the integration — that's where projects stall.
How we worked
Embedded System
One Team, Three Integration Partners We embedded alongside our client and Bellee's founding team — direct Slack access, daily standups, shared backlog. No ticket system, no account management layer. When an integration question came up with Uber's partner team, we were on the call.
Decision-making structure
Our client had final authority on business decisions (which kitchens to prioritise, what data Bellee needed, how to present performance to operators). Halcrow had technical authority on architecture decisions. We didn't seek permission for how to solve technical problems — we brought decisions that touched business direction.
The integration approach: Rather than waiting for all three platform integrations to resolve simultaneously, we sequenced. Uber Eats first — largest order volume, most developed partner program, fastest path to API access. Build the data pipeline for Uber Eats, validate the dashboard concept, then use the working integration as evidence when approaching Menulog and DoorDash.
Law 5: Earlier beats perfect. A working Uber Eats integration in six weeks beats a perfect three-platform integration in six months.
Continuous deployment
Each kitchen connection validated before the next was added. The dashboard received real data from real kitchens from week six. Our client could see orders moving. Operators could see their own performance. The product was live — incrementally — not launched as a big bang.
WHY THIS WORKED
The Facilitator Problem Bellee's integration challenge was genuinely novel. Most restaurant technology is built for single-merchant operations. Bellee's model — one technology layer across 20 separate merchant accounts — required a custom authentication approach that the delivery platforms hadn't explicitly designed for.
We solved this by approaching Uber Eats as a partner conversation, not a documentation implementation. When the API documentation didn't cover Bellee's model, we asked. When the standard merchant registration flow didn't fit, we described the model to someone who could grant appropriate access.
This is what embedded proximity enables: When the answer isn't in the documentation, you need someone who can have a conversation, adapt in real time, and bring the right technical context to a business negotiation. An offshore development team working from a spec document can't do this. A team embedded in the project can.
The Data Advantage
Our client's original hypothesis was that the technology layer would give Bellee's kitchen operations a competitive advantage. The dashboard revealed the advantage was bigger than he'd anticipated.
Bellee could now see that certain operator categories (Asian cuisine, high-volume) performed better during specific shifts in specific locations. This was data no individual restaurant operator had — they only saw their own performance. Bellee, as the aggregator, saw patterns across the whole portfolio.
That portfolio intelligence became Bellee's actual competitive moat: not just cheaper kitchen space, but data-driven operator support that standalone operators couldn't access.
The Pattern This Reveals
Platform integration projects almost always stall on access, not code. If you're building a technology layer that depends on connecting to third-party platforms (delivery, payments, logistics), the critical path question isn't "can we build the integration?" It's "can we get access to build the integration, and what does the partnership relationship look like?"
The teams that move fastest on this are the ones who treat the access conversation as parallel to the technical build — not sequential. Start the partner conversation on day one. Build the integration while the conversation progresses. Don't wait for full API access before starting the architecture.
what you're buying
If you're building a technology layer on top of third-party platforms — delivery, payments, marketplaces — speak to us.
Ready to turn your platform data into a competitive advantage? Contact Sam on 0431197004 or sam@halcrow.com.au.
—-
Case study written May 2026. Bellee is a real client. Uber Eats, Menulog, DoorDash, and Doshii are real platforms. All data sourced from project documentation, sprint records, and technical handover notes.
See how other teams are winning with Halcrow
Paper scafftags were a safety and compliance liability. We built the digital system from scratch — and the SaaS product now runs independently.
Metric #1
Metric #1 description
Read more
