The Case for Purpose-Built Infrastructure

Every industry reaches a point when the tools available—though individually capable—fail to compose a coherent system. Restaurant technology hit that point years ago. But oddly, the developer infrastructure never caught up.

Crave.js was born out of this recognition: while modern commerce frameworks like Shopify Hydrogen have redefined how developers build for retail, no equivalent exists for restaurants. This is not a gap in tooling—it’s a gap in worldview.

Restaurants are not simply another flavor of eCommerce. They operate on ephemeral inventory, dynamic menus, and real-time fulfillment, often under intense operational constraints. Yet developers trying to build custom restaurant ordering systems are still handed SKU-based frameworks and checkout pipelines originally designed for shipping t-shirts. That approach quickly runs into structural limits—modifier logic becomes brittle, live prep tracking has to be bolted on, and integrations with kitchen printers or POS systems become bespoke projects.

Through our experience supporting F&B ordering infrastructure at restaurants, golf courses, and hotels, we've repeatedly run into the same bottleneck: integrations. Connecting with POS systems, property management software, and accounting platforms is slow, gated, and costly. Crave.js is built to eliminate these barriers, offering pre-built connectors and standardized interfaces to let developers ship faster without sacrificing flexibility.

Restaurants require real-time adaptability—switching menus on the fly, tracking item status through preparation, and routing orders intelligently to different stations. Shopify doesn't support any of these operations natively. It lacks state machines for food order lifecycles, the ability to split tickets by vendor or station, and granular checkout control. These aren’t advanced features—they’re the minimum bar.

Crave.js solves this from first principles. It’s a headless framework architected specifically for on-demand commerce. Menu logic is intent-based (e.g. lunch menus are available from 11am to 2pm). Orders flow through reactive, event-driven states (i.e. orders exist in a state machine that listens to events and transitions automatically). And integrations—whether it’s Stripe, Square, or kitchen display systems—are core to the architecture, not bolted on.

What we’re building is more than technical infrastructure—it’s conceptual alignment. Crave.js is not eCommerce software retrofitted for restaurants. It’s restaurant-native software built to scale with developer ambition. The way Hydrogen changed how developers approached storefronts, Crave.js does the same for food.

We’re not here to replace existing tools. We’re here to eliminate the need to rebuild them from scratch.

Crave.js is built on two foundational principles:

1. Develop once, operate everywhere. A unified semantic model for menus, orders, and fulfillment allows developers to create consistent experiences across all channels—web, mobile, kiosk, QR—without duplicating logic.
2. Comprehensive template library. Ready-to-deploy templates for common food scenarios—from modifiers and checkout flows to daypart logic—dramatically reduce time-to-launch without sacrificing control.

Crave.js is the first framework to reimagine restaurant software as programmable infrastructure. It starts with an overdue idea: restaurants, too, deserve developer-grade tools.