What is DineGlobe

DineGlobe is a direct-booking reservation system for restaurants and similar venues. A guest books on the venue’s own public page, availability is computed against the venue’s real floor plan, and the venue’s own booking terms apply — there is no marketplace in the middle, no ranking to buy, and no commission layer between a venue and its guests. The product runs today as a free, single-market pilot at https://dineglobe.com.

Direct bookings, on the venue’s own floor plan

Every published venue gets a public page at /{slug} and a booking flow at /{slug}/book. What makes DineGlobe different from a listing site is what happens behind the “Find a table” button: the offered times come from the venue’s actual areas, tables and approved table combinations, and the booking takes a real, database-enforced hold on those tables. Two parties can never hold the same table at the same time — that is enforced in the database itself, not by convention.

The venue also owns the rules of the booking:

• Services (an offering such as “Dinner”) carry the venue’s weekly schedule, a notice window (how close to start a guest may book online) and a booking horizon (how far ahead).
• Booking policies are versioned. Free-cancellation windows, late-cancellation and no-show retention, and grace periods are published as immutable policy versions; a cancellation is quoted against the version the guest accepted, never against whatever the venue would publish tomorrow.
• Money is exact. Amounts are integers in the currency’s smallest unit. There is no floating-point money and no automatic currency conversion anywhere in the product.

Equally important is what DineGlobe does not try to be: no reviews or ratings, no marketing campaigns or loyalty points, no events or ticketing, no hotel rooms, no marketplace-style placement. Those are outside the product’s current scope, and nothing in the system pretends otherwise.

The pilot, stated plainly

DineGlobe runs as a single-server pilot deployment on one shared development host; no availability or recovery promises are made. Bookings are free — no charge, deposit or capture takes place — and service is limited to one approved country.

Single-market pilot evidence only: one approved country and its listed capabilities do not constitute global support; unlisted countries and capabilities stay disabled.

This is the same scope statement the product itself displays on its landing and about pages, and it is quoted wherever launch posture is discussed. Paid bookings and SMS stay disabled until each country and provider gate passes a signed readiness review — the gate evidence is recorded, never assumed.

The main surfaces

Surface	Where	What happens there
Guest venue pages	/{slug}	The venue’s public profile: name, city and timezone, description, a “Good to know” policy summary, and a “Book a table” button when online booking is open.
Guest booking	/{slug}/book	Pick a service, party size and date, choose a computed time, and book — no account needed. A confirmation code (DG-XXXXXXXX) is issued immediately.
Staff console	/app (sign-in at /app/login)	The working surface for venue staff: the day’s board, walk-in and phone intake, arrivals and seating, cancellations and no-shows, guest links, and account security.
Guest self-service	/b	A guest who received a private link can view, reconfirm or cancel that one booking and download a calendar file — nothing else.
Platform console	/app/panels	Internal operator surfaces: publication reviews, capability flags, support cases, readiness checks. Not part of venue day-to-day work.

If you want to see all of this without creating an account, the landing page carries a one-click demo for every staff role on a seeded venue — see Try the live demo.

What stays off during the pilot

• Paid bookings. Services configured with a deposit refuse online with a clear message — “This service requires a deposit, which is not available online yet. Please book by phone.” (PAID_BOOKING_UNAVAILABLE). No fake provider success exists anywhere in the code.
• SMS. The message machinery exists and is gate-tested, but no SMS provider is configured, so nothing sends.
• Email sending. Confirmation emails are composed from reviewed templates and queued in a durable outbox, but with no provider configured during the pilot the dispatch dead-letters visibly (PROVIDER_NOT_CONFIGURED). The booking itself still confirms in the app with its DG- code; staff can see the failed delivery outcome and retry once a provider exists.
• Camera capture. QR check-in by camera is not built in the current version — the implemented path is scanning or typing the pass or confirmation code by hand at the door.

Where to go next

• Try the live demo — one-click sign-in per role on a seeded venue.
• Roles & what they can do — who may do what, and what a denial looks like.
• Glossary — every core term in plain language.
• What works today & known limits — the honest implemented/not list.
• Venues, slugs & publication — how a venue goes from draft to public.
• Making a booking — the guest booking flow in detail.