Food and drink

Pre-order and pickup for a food truck

A food truck posts where it will be today and takes pre-orders for a pickup window. Customers pay in the app, get a pickup code, and the truck sees an ordered queue on a tablet. Items sell out and disappear from the menu automatically.

Automatically generated draft

Written by machine against our own engineering playbook. The company is invented; the decisions are the ones we would make on a real build. A reviewed blueprint goes further — nine sections, agreed line by line, and it is what the build is tested against.

Section 01 · What has to work

The product's success depends on customers being able to pre-order and pay for food, and the truck seeing a simple, live queue of those orders.

Section 03 · Screens

Every screen, and what it is for.

  • ›Daily Setup — Truck owner sets today's location, hours, and menu. Saving their updates must be instant.
  • ›Menu — Customer views today's menu and location. Items and their availability must load instantly.
  • ›Checkout — Customer pays for their selected items. The final price calculation must be instant.
  • ›Order Status — Customer views their pickup code and live order status. Status updates must appear instantly.
  • ›Order Queue — Truck staff sees a live queue of paid orders. New orders must appear instantly.

Anything not on this list is not in version one. That is what keeps a fixed price fixed.

Section 04 · The data model

What it stores, and who can read a row.

ServiceDay

id uuid, owner_id uuid, location_text text, service_date date, starts_at timestamptz, ends_at timestamptz, is_active boolean

Access · Anyone can read if `is_active`. The truck owner can always read.

MenuItem

id uuid, service_day_id uuid, name text, price_cents int, initial_quantity int, available_quantity int

Access · Anyone can read if linked to an active `ServiceDay`.

Order

id uuid, service_day_id uuid, customer_contact text, items jsonb, total_cents int, status enum('pending_payment', 'confirmed', 'preparing', 'ready', 'completed', 'cancelled'), pickup_code text, payment_intent_id text, created_at timestamptz

Access · Owner reads orders for their `ServiceDay`. Customer reads via a secret link.

User

id uuid, email text, hashed_password text, role enum('owner')

Access · A user can read their own row.

Those access rules belong in the database, not in the screens. Someone who edits the address bar still cannot read a row that is not theirs — and the test that proves it blocks delivery if it fails.

Section 05 · States

pending_payment → confirmed → preparing → ready → completed | cancelled(reason)

Most scope arguments three weeks into a build are really arguments about a state nobody named at the start.

Section 06 · Where this breaks

What bites products like this one.

Concurrent orders for the last menu item could cause overselling, creating angry customers.

Use a database transaction with row-level locking to decrement inventory, ensuring atomic updates on quantity.

A customer pays but a network error prevents order confirmation in our system, leaving them charged but order-less.

Use payment provider webhooks as the ultimate source of truth for confirming an order in our database.

Section 08 · Deliberately left out

What version one does not do.

  • ×Persistent customer accounts. V1 uses guest checkout with an email/phone per order. Add accounts later for loyalty features.
  • ×Multiple, distinct pickup time slots. V1 uses one continuous window. Add slots when demand justifies throttling order flow.

This is the section that protects the date, and the only place in the document where somebody says no. It is also why clients trust the rest of it.

Still open

What we would ask before quoting.

  • Which payment processor will you use (e.g., Stripe, Square), and is your business account already approved with them?
  • How should customers receive their pickup code and order updates: via SMS, email, or a push notification?
  • What specific tablet model will the truck staff use to view the order queue?

Your product, not this one

Get this written for what you are actually building.

Describe it in a sentence and the generator returns the same sections for your own product. Free, no email, nothing saved to a list.

Next step

Find out if your idea fits in 10 working days.

Tell us what you want to build. We reply the same day with a straight yes, no, or here is what we would cut.

NDA available on request