Skip to content

About Dira

Restaurant commerce works better when everything works together.

Dira was built around a straightforward idea: restaurant brands should not have to operate a collection of disconnected systems just to move a digital order from a marketplace to the kitchen. We bring ordering channels, menu operations, restaurant workflows, and financial visibility into one connected platform.

Dira stands for Digital Restaurant Architecture.

The name describes the job. Each word is a commitment about how the platform is built.

Digital
Orders, menus, availability and payouts now move between marketplaces and restaurants as data. Dira treats that data as the operation itself, not a side channel.
Restaurant
Built around how stores, kitchens and finance teams actually work: rush periods, 86'd items, a POS that goes offline, a payout that does not match.
Architecture
A shared core with adapters at the edge. The structure is designed so a growing network adds locations and channels without adding disconnected systems.

What we believe

A few principles shape every product decision we make.

  • One order model.

    An order from any marketplace becomes the same canonical order. Stores, the POS, operations and finance all read one record with one history.

  • Operators stay in control.

    Automation handles the routine path. People see the exceptions, make the call, and every action is kept in an audit history.

  • Open interfaces.

    Documented OpenAPI 3.1 contracts and adapters at the edge mean a brand's systems connect to Dira without anyone rebuilding the core.

  • Recovery is part of the design.

    Systems go down. Idempotent processing, retries, replay and degraded modes keep orders moving when a POS or a provider is unavailable.

  • Honest status.

    We say what is integrated, what is in development and what is scoped per deployment. Integration code is not certification, and we never present it that way.

What Dira is made of

Six products. One shared core.

Each product handles one part of the work behind a digital order. All six read and write the same canonical orders, catalog, store identity and event history.

See how the platform fits together

How we build

Restaurant systems fail at the worst moments. We build for that: strict contracts, recorded events and containerized services.

Architecture and APIs

  • API-first

    Every capability is exposed through a strict OpenAPI 3.1 contract, and contracts are tested automatically in CI.

  • Event-driven

    State changes are written as events through an outbox, so every system downstream sees the same history in the same order.

  • Resilient by design

    Idempotent processing, retries, an error queue with replay and degraded POS modes are part of the core, not add-ons.

  • Observable by default

    Connections, queues and adapters report their health, so operators can act on a problem from Dira Command instead of chasing it across systems.

diraEvent history
{  "type": "order.accepted",  "orderId": "ord_sample_4821",  "channel": "ubereats",  "storeId": "store_0142",  "idempotencyKey": "ue:evt_sample_99c1",  "state": { "from": "received", "to": "accepted" },  "pos": { "status": "injected", "attempt": 1 },  "occurredAt": "2026-11-04T18:42:07Z"}
Illustrative canonical event · sample data

The current stack

Other cloud targets, such as Azure, are evaluated and contracted separately for each enterprise.

Services
Node.js and TypeScript with NestJS
Contracts
OpenAPI 3.1, contract tested in CI
Data
PostgreSQL with logical schemas and an event/outbox model
Packaging
Docker containers
Reference deployment
Google Cloud: Cloud Run, Pub/Sub, Cloud SQL, Cloud Storage, Redis

How we work with restaurant brands

Every network is different. A deployment starts from the systems you already run and is validated against them before any store goes live.

See integration statuses
  1. Scope

    Start from your systems.

    We map your channels, POS, store structure, menus and finance process, and agree which adapters the deployment needs.

  2. Connect

    Configure the adapters.

    Marketplace and POS adapters are configured for your brand, with catalog, store identity and pricing set up in Dira.

  3. Validate

    Prove it against your stack.

    Each POS connector and channel is tested with your systems and real order scenarios, including cancellations and outages.

  4. Operate

    Roll out and run.

    Stores come online in groups. Your teams work from Dira Command and Dira Store, with the error queue and audit history from day one.

Let's look at your restaurant network together.

Tell us how your orders flow today. We'll show you how Dira connects it.

Talk to the teamExplore the platform