# Build brief — a focused alternative to Gastrosync > **Verdict:** Partly, if you narrow it · **Buildability:** 42/100 · **Category:** CRM > **Source:** https://www.canitbevibecoded.com/gastrosync > Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from Gastrosync. Verify current pricing and capabilities before acting. ## Context **Gastrosync** — Turn venue enquiries into priced, signed offers and live event factsheets. A single venue can replace the Word, spreadsheet, and inbox loop in a focused implementation: capture an event enquiry, price it from a small catalogue, publish an offer for acknowledgement, and keep one operational factsheet current. Gastrosync becomes much harder to replace when several locations and teammates depend on permissions, document history, reliable delivery, regional tax and invoice rules, payment slips, and legally meaningful signed records. This brief describes a focused, single-operator replacement for the part of Gastrosync that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest. ## What you are building Move one venue's event enquiry through contact capture, itemized pricing, a shareable offer, customer acknowledgement, and an always-current operations factsheet. - Track contacts, log interactions, and queue follow-ups for a one-person pipeline. - A responsive interface with real empty, loading, success, and error states. ## Requirements ### Functional - Docker. - PostgreSQL. - Self-hosted server. ### Data and integrations - SMTP credentials for sending offer links. Each of these needs a real account, credential, or quota. Set them up before writing feature code. ### Non-functional - Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support. - Security: server-side secrets, validated input, and no credentials in the client bundle. - Reliability: retries with backoff on external calls, and a clear failure state when a provider is down. - Portability: the operator can export their data and leave without losing it. ## Implementation brief 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. ## Delivery standard - Inspect the repository first, then write a short implementation plan before writing code. - Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data. - Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations. - Include responsive layouts plus genuine empty, loading, success, validation, and failure states. - Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data. - Add structured logs around every external call and return actionable errors without leaking sensitive details. - Write unit tests for the core logic and one automated test of the main user journey. - Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations. ## Acceptance criteria - [ ] A clean install starts the app using only the README and .env.example. - [ ] The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable. - [ ] Invalid input, missing configuration, provider failure, and an empty database each have a usable state. - [ ] The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control. - [ ] Tests, type checking, linting, and a production build all pass with no ignored failures. - [ ] No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified. ## Non-goals Do not build these, and do not claim to have replaced them: - Multi-location authorization and team-wide shared workflows. - Production-grade signed-document freezing, auditability, and delivery guarantees. - Deep product catalogues, reusable templates, automations, and operational reporting. - VAT, deposit, final-invoice, cancellation, and reverse-charge edge cases. - Swiss and German payment slips plus ZUGFeRD EN16931 e-invoice behavior. ## What you still own after launch - Run migrations, backups, restores, and dependency updates. - Test the critical journey after every model, API, or hosting change. - Monitor failures and fix the edge cases a first prompt will miss. ## Risk **High consequence.** Use this as a prototype or personal aid. Keep a qualified human and an established provider in the loop for consequential decisions. Editorial confidence in this assessment: high. No reviewed project implementation is linked yet. --- Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/gastrosync