Tablefire POS — Restaurant, Café & Takeaway POS Software Website (Frontend + Backend)

8 pages and a real lead-capture backend — this is a DYNAMIC website for a restaurant / café / takeaway POS software company: every product page (features, kitchen & tables, WhatsApp, reports, pricing, FAQ) is static editorial content with HTML/CSS product mockups, while the "Book a Demo" form writes to your own database in real time. Design: warm charcoal and ember palette, Fraunces + Inter + JetBrains Mono, kitchen-ticket motif (perforated KDS tickets, POS terminal, floor plan and WhatsApp mockups built in HTML — no screenshots to replace). 1. Home (index.html) — hero with POS terminal mockup, stats, 6 feature cards, an interactive menu catalogue (12 dish cards with photos, category chips, search, live guest check), KDS / WhatsApp / reports showcases, testimonial, onboarding steps. 2. Features (features.html) — 9 numbered sections: ordering (dine-in, takeaway, delivery), tables, kitchen tickets & KDS, menu & modifiers, recipe inventory, split bills / discounts / taxes / tips, WhatsApp, daily & cashier reports, manpower & expenses. 3. Kitchen & Tables (kitchen.html) — live floor plan, KDS board, printed kitchen tickets, three service modes. 4. WhatsApp (whatsapp.html) — message flow phone mockup, setup steps, benefits. 5. Reports (reports.html) — daily sales, cashier cash-up table, a print-ready 80mm guest check, manpower and expense entries, food cost. 6. Pricing (pricing.html) — 3 plans, comparison table, hardware. 7. FAQ (faq.html) — 11 grouped questions. 8. Book a Demo (demo.html) — the real demo request form. WHOSE DATABASE, WHOSE EMAIL PROVIDER. Yours, not this platform's. Before anything here does something real: 1. Create a Postgres database anywhere you like — Vercel Postgres, Supabase, Neon, or your own server — and run schema.sql against it once. 2. In your Vercel project's Settings -> Environment Variables, set: DATABASE_URL your database connection string RESTAURANT_DEMO_REQUESTS_ADMIN_KEY any secret string you choose Optional, for automatic email confirmations on new requests: RESEND_API_KEY from your own Resend (resend.com) account RESTAURANT_DEMO_REQUEST_FROM_EMAIL an address on a domain verified in that account Without the two optional variables set, requests still save correctly — no confirmation email sends, that's all. MANAGING DEMO REQUESTS. Once published, this purchase's library page shows a "Manage live data" panel — paste in your RESTAURANT_DEMO_REQUESTS_ADMIN_KEY to see every demo request as it comes in, mark it contacted, and delete ones you've handled. MANAGING YOUR MENU. The same "Manage live data" panel has a second table for the Home page catalogue (restaurant_products, served by api/restaurant_products.ts). With the same admin key entered, add, edit and delete your dishes and drinks: name, category, price, a short description line, an optional badge, and a photo uploaded straight from your computer (resized in your browser and stored in your own database, so there's no separate file storage to set up). While the table is empty the catalogue shows its built-in samples; as soon as you add your first item, your list replaces them. Your categories become the filter chips, and prices use the currency symbol already written on the page. Changes appear on the live site on the next page load, with no republish needed. SPAM PROTECTION. The demo form includes a hidden honeypot field real visitors never see or fill — a submission with it filled in is accepted (so a bot never learns it failed) but silently discarded, checked both client-side and in api/restaurant_demo_requests.ts. WHAT YOU CAN CUSTOMIZE, HONESTLY: - Every page's copy, prices, mockup contents, images and layout — through the same AI-guided editor as any other template, no coding. - One optional field at a time on the "restaurant_demo_requests" resource (for example, "current POS" or "preferred demo time"), through the "Backend customization" panel once purchased. Fields are always optional, so existing requests are never affected. - The POS screens on this site are marketing mockups, not a working POS. Building real ordering, payments, WhatsApp sending or a customer portal isn't something the editor automates — every purchase includes the full source code so you or a developer can extend it. INTERACTIVE MENU & 80MM PRINTING. The Home page menu catalogue really works in the browser: tap dishes to build the guest check, filter by category, search, remove lines, and press "Print receipt · 80mm". The Reports page has a print-ready sample guest check with its own Print button. Both open the browser print dialog with a page exactly 80 mm wide (72 mm printable, black monospace, height sized to the receipt) — select your thermal receipt printer and its 80mm roll paper size, margins none. Dish names, prices, categories and the receipt header are ordinary text you can edit; the cart reads them straight from the page. The tax rate comes from the "8.5%" on the guest check. Sales rung up here are a demo, not a connected POS: the cart itself stores and sends nothing. PREVIEW LIMITATION. The demo form calls a real endpoint that only exists once deployed — this platform's preview has no backend to call, so it shows a friendly "try it once deployed" message here. That's expected. The catalogue shows its built-in samples here for the same reason. CLAIMS & COMPLIANCE. Statistics, prices, customer counts and the testimonial are realistic placeholders — replace them with your own verified figures before publishing. WhatsApp messaging claims assume the WhatsApp Business Platform with guest opt-in; keep that note if you keep the feature. The product name, restaurants and people named are fictional. IMAGES. All photography is real, licensed-for-web Unsplash stock, self-hosted under /content-images. 1 photo — the chef on the Kitchen & Tables page hero — depicts an identifiable person and must be replaced before commercial use (right-of-publicity, not copyright). Food, venue and delivery photography may be kept as-is.