Skip to content

Founder-led software for ordering, booking, payments, and admin systems

EDWORX LLC logoEDWORX

One stack, three surfaces

Home Fire Pizza OS: one operating stack across customer ordering, web presence, and operator control.

This is the full Home Fire Pizza system in production: the public homefire.pizza website, the published Android ordering app, and the private operator dashboard for menus, availability, and order flow. Together they run as one connected OS, backed by a single catalog and order pipeline.

Home Fire Pizza: marketing website on a desktop monitor, operator admin dashboard on a laptop, and customer mobile app on a phone.

Home Fire Pizza operating system

Home Fire Pizza runs on three connected surfaces: a public website for discovery and ordering entry, a customer mobile app for repeat purchase flow, and a private operator CMS for menu, availability, and order operations. The tabs below show how each surface contributes to one production system.

Visit homefire.pizza

Full operating system view

This composite shows how the customer-facing and operator-facing surfaces connect: the branded website drives discovery, the ordering experience captures demand, and the private operations layer keeps menus, availability, and fulfillment aligned.

Home Fire Pizza composite showing website, customer mobile app, and operator dashboard as one connected production stack.

Home Fire Pizza codebase

93,000+

lines of tracked source

Counted across the five production repos (web, mobile, APIs, CMS), dependencies and build output excluded.

5

production repositories

Each repo owns a dedicated slice (web, mobile, APIs, CMS) so changes stay reviewable and deployable on their own cadence.

12

major capability pillars

Cross-cutting behaviors that had to stay coherent across web, Android, and operator tooling, not a brochure plus a plugin.

Application source counted across the five production repositories (TypeScript/JavaScript, Kotlin-leaning Android, JSX/TSX, styles/config, SQL, etc.), excluding node_modules, generated build output, and vendored blobs. Totals move slightly depending on which extensions you include, this is an order-of-magnitude anchor, not a contract line item.

Where the code lives

  • homefire.pizza

    Public website

    Branded discovery, storytelling, ordering entry.

  • Home-Fire-Pizza-PROD

    Android app codebase

    Native ordering UX, menus, cart, checkout, accounts, loyalty-ready flows.

  • home-fire-api

    Core ordering API

    Square catalog and payments, persistence, reconciliation with apps and web.

  • home-fire-wait-api

    Kitchen wait service

    Live estimate / queue telemetry surfaced to guests and operators.

  • home-fire-cms-dashboard

    Operator CMS

    Private dashboards for menus, availability, orders, and analytics.

The 12 pillars that ship together

  • Branded public site with frictionless paths into ordering
  • Square-backed menus, modifiers, and settlement-aware checkout
  • Native Android experience for carts, confirmations, loyalty hooks
  • Pickup schedules aligned to ovens, trucks, and event calendars
  • Live kitchen-status and estimated waits on customer surfaces
  • Supabase-backed data where shared state crosses channels
  • Private CMS workflows that change menus without redeploying apps
  • Order-management views for pickups, timelines, exceptions
  • Customer accounts plus order-history and continuity
  • Email receipts, confirmations, and operational notifications
  • Staff-facing dashboards and reporting slices
  • Cross-surface consistency so web, mobile, and admin stay coherent

Live customer stack

Home Fire Pizza: how this stack runs day to day

Direct-order restaurant and food-truck systems in production at homefire.pizza.

Website, Android ordering app, Square catalog and checkout, Supabase data, pickup scheduling, loyalty, and operator tooling. One catalog and checkout pipeline feeds the website, Android app, and operator tools so menu items, modifiers, payment state, and order records stay coherent when nights shift, trucks move, or pickup windows tighten.

Built for a real seasonal wood-fired pizza business: live menu data, mobile ordering, Square-backed checkout, private operator CMS, and workflows tuned for event-based food truck nights.

For restaurants, food trucks, and seasonal food businesses, EDWORX builds direct ordering that reflects the brand and keeps the relationship with the customer. Customers stay oriented to Home Fire Pizza's site and app, not locked into a generic third-party ordering shell, while operators still rely on Square-backed catalog truth underneath.

Plan a Restaurant System

Surfaces & integrations

Feature details; expand each row for more information.

Visitors land on a wood-fired narrative, service context, and clear paths straight into ordering, not a brochure that dumps people into a generic marketplace. Same brand voice whether they browse on desktop or thumb through the menu on mobile.
The listing on Google Play is Home Fire Pizza's owned repeat-order channel: browse, modifiers, cart, checkout, confirmations, account continuity, and workflows that stay ready when you flip on loyalty or pushes, without living inside a delivery app shell.
Items, modifiers, and settlement run through Square on the merchant's account.EDWORX's APIs fetch catalog snapshots, assemble carts, POST payments with idempotency, and reconcile confirmation so web, Android, and admin never disagree on what is sold or charged.
Staff tune categories, pizzas vs. rolls vs. drinks, add-on rings, sold-out pivots, and schedule shifts from the private CMS dashboards, customers pick up changes on web and Android from the pipeline, not from an engineer redeploy.
Wood-fired gigs move between brick hours, brewery lots, and private events; the stack models tight pickup windows tied to ovens and calendars and pairs with backend services like the kitchen wait APIso guests aren't guessing when their pie clears the fire.

Private dashboards, payment internals, and staff-only workflows are easiest to explain in a walkthrough. This breakdown focuses on shipped production behaviors you can inspect on the public side above.

FAQ

Questions about this build

How Home Fire Pizza runs in production, what stays private, and how builds like this map to EDWORX setup and monthly support.

The public homefire.pizza site, the published Android ordering app on Google Play, the core ordering API (Square catalog, payments, order persistence), a kitchen wait service that feeds live estimates, and a private operator CMS for menus, availability, and order operations. Together they run as one production system, not a marketing site bolted onto a separate ordering vendor.

Square holds catalog and modifier truth and processes payments into Home Fire Pizza's own merchant account. Customers stay on the brand's website and app; EDWORX integrates and maintains the pipeline so web, Android, and admin surfaces all read the same menu and checkout state.

Shared APIs load catalog snapshots, persist carts and orders in Supabase-backed flows where needed, and expose order and availability state to both customer surfaces and the private dashboard. Operators change menus or pickup rules in CMS; guests see those updates without an app-store redeploy for every tweak.

When ovens and event nights create real queue pressure, the stack can surface live wait context so customers understand timing on the channels you enable. It is part of the same operational picture staff use, not a disconnected “widget.”

No. The CMS is private staff tooling (screenshots on this case study are illustrative). Customers use homefire.pizza and the Android app; operators use the dashboard for day-to-day control.

Usually no. The business pays Square processing fees directly; EDWORX charges setup and monthly support so production software stays maintained. That model matches how this case study is positioned: own the customer relationship, not rent it inside a marketplace take-rate.

Home Fire Pizza is a Full Digital Stack–class reference: branded web, native Android depth, payments, accounts/loyalty-ready flows, and private admin. Smaller restaurants might start in the Ordering or Booking System tier and phase mobile or CMS depth; this production stack shows what the top anchor can look like when those pieces ship together.

Hosting and monitoring, dependency and security updates, bug fixes, small menu or configuration changes, payment integration maintenance, basic reporting, and email support, so the five-repo footprint you see here does not go stale. New major features are scoped separately; see public pricing for what is in and out of scope.