Should you build your own Gastrosync?

Build a working single-venue event sales tool in an empty repository.
Use Ruby 3.4, Rails 8, Hotwire, Tailwind CSS, PostgreSQL, and Docker Compose; do not offer alternative stacks.
The core loop is: capture an enquiry, price the event, share an offer, record customer acknowledgement, and publish the current operations factsheet.
Make the first run work with one documented Docker command and seed a clearly labelled demo venue.
Implement one private venue account with users, contacts, events, event status, dates, guest count, rooms, notes, and an activity timeline.
Add a small reusable catalogue of food, drink, room, staffing, and equipment items with quantity, unit price, VAT label, and optional notes.
Let staff turn an event into a versioned itemized offer with totals, expiry date, terms, and PDF download.
Publish each offer at an unguessable signed URL where the customer can review it and acknowledge it with name, email, checkbox, and timestamp.
Treat acknowledgement as workflow evidence, not a qualified electronic signature, and say that clearly in the UI and README.
After acknowledgement, preserve a read-only JSON snapshot and PDF while allowing staff to create a new revision.
Generate a shareable factsheet from the latest accepted offer plus event timings, contacts, setup notes, dietary notes, and assigned staff.
Keep the factsheet live as operations notes change and provide a print-friendly PDF.
Send offer and acknowledgement emails through SMTP with retries, idempotency keys, visible delivery status, and a local mail preview in development.
Provide full JSON export, daily backup instructions, audit events for every status or document change, and clear empty and failure states.
Enforce owner and staff permissions on every mutation; validate inputs and never log secrets or private document contents.
Write focused tests for totals, offer revisions, acknowledgement locking, permissions, and factsheet rendering plus one end-to-end happy path.
Put secrets in .env, ship .env.example, and add install, test, lint, build, backup, and production-run scripts.
Deliberately exclude multiple venues, granular branch authorization, collaborative editing, calendar or accounting integrations, payments, and native mobile apps.
Deliberately exclude legally qualified signatures, jurisdiction-aware VAT advice, invoices, cancellation documents, QR payment slips, and ZUGFeRD or EN16931 claims.
Create a README covering setup, data location, email, permissions, backups, security assumptions, and every excluded production feature.
Finish by running the tests and production build and list the exact commands used.