Short answer
Gula was RaftLabs' own product, a B2B food tech platform in Indonesia consolidating Gofood, GrabFood, and ShopeeFood orders into one web and tablet interface, integrating with POS systems to feed one kitchen printer. Zero order errors since launch, 50 restaurants onboarded in its first month, delivered in 16 weeks. Co-built with co-founder Grady Lakshmono; subsequently acquired by Runchise.
The situation
Indonesia's food delivery market grew fast. The problem it created for restaurants grew with it.
A restaurant active on GrabFood, GoFood, and ShopeeFood was running three separate tablets (one per platform). When an order arrived, staff had to check each screen, enter the order manually into the kitchen system, and hope nothing slipped between the cracks. During busy periods, orders missed. During quieter periods, all that complexity still ate into staff time and owner attention.
Grady Lakshmono had seen this problem from multiple angles as an operator of food businesses himself. We co-built Gula with him as our own product: RaftLabs built the platform and held a stake in it, so this was not a client engagement. Gula is a B2B platform that replaces those three tablets with one screen, connects to the existing POS, and routes every order directly to the kitchen printer without manual steps.
We built the platform in 16 weeks. The client reported that since launch, Gula maintained zero order errors, and that 50 restaurants joined in the first month.
Three or four tablets going bonkers with orders coming in, while customers pour through the door: that is the scene this replaces. And the deeper problem is not the tablets. It is the rekeying. Staff taking orders from tablets and typing them into the till again, with a meaningful share of orders keyed in wrong. The tablet farm is the symptom. The manual transfer is the error.
Engagement
The Gula engagement
- Client
- Grady Lakshmono, a food business operator, co-building with RaftLabs as our own product
- What we built
- Gula, a B2B platform that replaces three delivery-platform tablets with one screen: orders from GrabFood, GoFood, and ShopeeFood flow to the kitchen printer via POS integration, menus update centrally
- Delivery
- 16 weeks, concept to live MVP
- Stack
- Multi-platform API integration layer, POS integration, real-time order feed
- Status
- Live. The client reported 50+ restaurants onboarded in the first month
Before and after
What changed
- Restaurants managed three separate delivery platform tablets (one for GrabFood, one for GoFood, one for ShopeeFood)
- Staff manually transferred order details from each delivery app into the POS system
- Orders during busy periods regularly slipped between platforms, leading to fulfillment errors
- Menu updates had to be repeated on each delivery platform separately
- No unified view of orders, revenue, or performance across platforms
- Promotions and store hours required manual updates on each platform independently
- All delivery platform orders appear in a single web and tablet interface
- Order details flow automatically from the dashboard to the kitchen printer via POS integration
- Zero order errors since launch: no manual transfer, no missed notifications
- Menu updates made once in Gula propagate to all connected delivery platforms
- Real-time analytics show orders, revenue, and performance across all platforms in one view
- Promotions and store hours managed centrally with one update
What we had to solve
Connecting to three delivery platforms with different API architectures
GrabFood, GoFood, and ShopeeFood each built their platform independently. Their APIs use different authentication methods, different data formats, and different webhook patterns for order notifications. Building a single integration layer that could receive an order from any of the three, normalize it into a consistent internal format, and route it to the right output (POS system, kitchen printer) required careful mapping work for each platform. Any gap in the normalization logic would produce a malformed order that kitchen staff couldn't read.
Keeping the interface fast enough for a busy kitchen
A restaurant tablet during a Friday dinner rush is not like a back-office dashboard. Orders arrive in bursts, staff are moving fast, and a two-second lag between an order landing on the platform and appearing on the tablet is the difference between a smooth service and a missed ticket. The real-time order feed had to be genuinely instantaneous (not just "fast by developer standards") and the interface had to surface the right information at a glance without requiring staff to read through a full order detail screen.
Proof
What the client reported, and what this page can't claim
Operational figures reported by the client after launch. These are operator reports, not independently audited measurements.
| Result | What changed | Period or context | Evidence and limitation |
|---|---|---|---|
| Adoption | 50+ restaurants onboarded in the first month | Indonesian restaurants running GrabFood, GoFood, and ShopeeFood through one screen | Client-reported |
| Order accuracy | Zero order errors since launch | Orders flow from the delivery platforms to the kitchen printer without manual rekeying | Client-reported. The error rate in manual transfer was the problem this replaced |
| Time to launch | 16 weeks from concept to a live MVP | Integration layer across three delivery platforms with different API architectures, plus POS and kitchen printer routing | Project-recorded |
the build
What we built
The platform has two sides: a real-time order management screen for restaurant staff, and a control panel for owners to manage menus, promotions, and analytics across every delivery partner.
All orders on one screen, no app-switching during service
Orders from GrabFood, GoFood, and ShopeeFood appear in a single feed on the web and tablet interface. Staff see all incoming orders in one place without switching between apps. When an order is confirmed, the details flow automatically to the kitchen printer via the existing POS connection.
This is the piece that replaces the three-tablet setup directly. Instead of watching three screens during a rush and hoping nothing lands on the one nobody's looking at, staff work from a single sorted queue, oldest or most urgent first, with the source platform shown as a label rather than a separate app to check.
One update changes menus on every delivery platform
Owners update their menu once in Gula and the changes propagate to all connected delivery platforms. The same applies to promotions, pricing, and store hours. What previously required three separate logins and three separate updates takes one.
Before this, marking an item sold out meant three separate edits made one after another, with a real gap in between where a platform could still take orders for food the kitchen no longer had. A single toggle here closes that gap across all three at once, so there's no window where one app knows and the other two don't.
Kitchen knows what's active without checking twice
Staff see each order's live status from the moment it arrives to the moment it is picked up by the delivery driver. No manual checking across platforms. No confusion about which orders are active and which are complete.
That status line is what keeps a busy kitchen from losing track of a ticket. An order sitting as "cooking" for longer than it should, or "ready" with no driver assigned yet, is visible at a glance instead of something a staff member has to notice on their own while juggling three other tickets.
Owners see revenue across all platforms in one view
The owner dashboard shows total orders, revenue, and performance data across all delivery partners in one view. Owners can filter by platform, date range, and outlet, and see which menu items perform best on which platforms. Data that was previously scattered across three apps is now in one place.
An owner running several kitchens on three platforms previously had no quick way to tell whether a slow week was a location problem or a single platform underperforming. Breaking revenue down by kitchen and by platform in the same view answers that directly, and surfacing the peak order hour means staffing decisions come from the data instead of a manager's memory of last week.
The lesson
The tablet farm is the symptom
Three tablets on the counter looks like a hardware problem. It is not. The tablets are the visible part of a manual process: staff reading an order off one screen and typing it into another system, during a rush, while customers wait. That rekeying is where the errors live, where the missed tickets live, and where the staff time goes.
Gula's design decision was to eliminate the transfer, not to tidy the tablets. Orders land on one screen and flow to the kitchen printer without a human in the middle. Menu updates happen once and propagate everywhere. The moment the manual step disappears, the error rate it produced disappears with it. Automate the handoff, not the screen.
How it runs
- React
- The order management interface needed to update in real time as orders arrived from multiple delivery platforms simultaneously. React's component model made it practical to build a live order feed that refreshes individual items without reloading the full screen.
- Ant Design
- Gula's core users are restaurant operators, not developers. Ant Design gave us a production-ready component library built for dense data interfaces (tables, forms, status indicators) which meant less time building UI primitives and more time on the integration logic.
- Node.js
- The backend receives webhook events from three delivery platforms simultaneously, normalizes them, and routes them to POS and kitchen systems in real time. Node's event-driven architecture handles this concurrent I/O efficiently without the complexity of a thread-based approach.
Common questions
Yes. Gula integrates with existing POS systems so order details from all delivery platforms flow automatically to the kitchen printer in the right format. The specific integration depends on which POS you use; most major systems used in Indonesian food businesses are supported. Contact us to confirm your setup before you start.
A restaurant connects its delivery platform accounts to Gula once during setup. The menu is imported from the existing listings or entered directly. After that, orders from all connected platforms appear in the unified interface without any daily setup. Most restaurants are live within a day of completing the account connections.
Each delivery platform has its own menu structure, pricing rules, and item categorization. Gula normalizes these into a single menu format on the backend. When an owner updates a price or description in Gula, the platform maps that change to the correct fields on each delivery platform's API automatically.
The platform monitors the connection status of each delivery integration and alerts the operator if a platform becomes unavailable. Orders from the remaining active platforms continue flowing normally. When a platform restores service or updates its API, the integration layer handles the reconnection without operator involvement.
We delivered the core platform (unified order management, POS integration, menu control, and analytics) in 16 weeks. A more complex build with additional delivery partner integrations or custom POS connections would take longer. The starting range for a platform of this type is typically $25,000-$50,000 depending on the number of integrations and feature scope. Contact us for a detailed estimate based on your requirements.
Related work
More work like this
Grubly processes 10,000+ restaurant orders while saving owners $5,000 in third-party delivery commissions
Grubly lets restaurants own their online ordering channel. 10,000+ orders processed, $5,000 saved in delivery commissions in the first 15 days, and a direct customer relationship that third-party platforms do not allow.
AI phone agents automate global feedback loops through voice interviews
Text surveys only reached people comfortable filling out forms. We built a voice platform that calls anyone with a phone, runs the interview, and has the findings ready when the last call ends.
Gas station management software case study: Gilbarco POS sync and AI invoice scanning
A gas station management platform for a 40+ station US operator: two-way Gilbarco Passport sync, AI invoice scanning, and inventory rules for refills, boxed stock, and expiry dates.