DEV Community

Redman WorkflowAlpha
Redman WorkflowAlpha

Posted on

Veloce-Engine: I Added a Reservation, Confirmed It, Then Hit Refresh — What the Demo Does and Doesn't Prove

The short version

Before I spend money on a $199.99 one-time license for restaurant software, I want to know one thing: is the demo real, or is it a screenshot with a form glued on top?

I went into the Veloce-Engine demo expecting the usual "coming soon" wall. Instead I got a working dashboard I could actually break. Here's what I did to it, what survived, and what that tells a buyer.

Try it yourself: https://reggiebro.github.io/WorkflowAlpha.ai/veloce-engine/


What I did, step by step

1. Opened the page. It loads with seeded data already in it — 4 reservations and 3 staff marked online. That alone is a good sign. A fake demo usually ships empty and waits for you to do the work.

2. Added a reservation. Guest name, phone, date, time, party size, special requests. Hit Add Reservation.

  • Reservations counter: 4 → 5
  • Pending counter: went up by one
  • The new row appeared in the table immediately

3. Changed its status. Each row has a <select> — not a toggle, a dropdown — with four states:

Pending → Confirmed → Seated → Completed
Enter fullscreen mode Exit fullscreen mode

That four-state pipeline matters more than it looks. "Confirmed" and "Seated" are different questions in a restaurant: confirmed means the booking exists, seated means a human is physically at a table. Plenty of tools collapse those into one "done" flag and then can't answer "who's actually in the building right now."

4. Hit refresh. This is where it got honest.

Before refresh After refresh
Reservation rows 5 4
My test reservation present gone

The demo holds its state in memory. Nothing I did was written anywhere. I confirmed the same thing in the page source: no fetch(), no XMLHttpRequest, no localStorage, no indexedDB anywhere in the page. There is no backend behind the demo at all — it's a single self-contained page with state in JavaScript variables.

So the demo is a UI prototype, not a live instance. That's worth saying out loud, because it cuts both ways.


What the demo proves

  • The interface is real and interactive. Add, status-change, and delete all work without a page reload. You are not looking at a mockup.
  • The status model is four-state, which is the right shape for front-of-house work.
  • The staff roster renders with role and status. The seeded list: John Doe (Manager, Online), Sarah Miller (Server, Online), Alex Kim (Kitchen, Online), Lisa Nguyen (Bartender, Break), Mike Ross (Host, Offline).
  • The "Staff Online" counter is 3, not 4. That's the detail I liked most. A person on Break is not counted as Online. That distinction is a labour-scheduling question, and whoever built this thought about it.
  • The Shifts tab works. Five seeded shifts, each with staff, start, and end. I added a sixth (John Doe, 09:00–17:00) via the Add button and it appeared instantly. Every row has a delete ✕. Times are plain 24-hour inputs — including 16:00 – 00:00, an overnight shift that doesn't break the renderer.

What the demo does not prove

  • Persistence. Proven above — refresh wipes it.
  • Concurrent access. There is no server, so there are no two waiters editing the same table at once.
  • The booking pipeline from your website into the dashboard. Not visible in the demo.
  • The staff chat actually delivering messages. The tab exists and renders; delivery mechanics are not exercised here.

If you're evaluating this, that list is your real test plan. The demo answers "does the interface make sense?" It does not answer "will it survive my Saturday night rush?" Only the deployed version can answer that.


What you're actually buying

The $199.99 license is not a SaaS subscription. From the product page:

  • Full source code — frontend, backend, database schemas, API layer
  • Deployment scripts for your infrastructure
  • Complete documentation — admin guide, API reference, user manuals
  • 30-day post-deployment support
  • White-label ready — your branding, no Veloce-Engine branding visible to staff or guests

It's a one-time payment, and custom deployment on your own servers is included in the license. Your domain, your data. No per-seat pricing, which is the number that usually kills a 12-person venue over three years.


How to pay

Three routes, all listed on the page:

  • PayPal — send to redman1309@proton.me. Write a note with your order, and the seller confirms it in their inbox. PayPal buyer protection applies.
  • Crypto — 0x078fE079A9440631Bc6AD722D7143dC382b4ea4f on the Base network. ETH, USDC, and USDT accepted.
  • Western Union / MoneyGram

To start: email workflowalpha.ai@gmail.com with your business type, number of locations, and team size. They confirm the license covers your operation, send payment instructions, and deploy once payment clears.


Bottom line

I can't tell you Veloce-Engine will run your restaurant — I haven't deployed it anywhere, and neither has the demo. What I can tell you is that the demo is a genuine, interactive front end with a sensible four-state reservation pipeline, a staff roster that distinguishes Online from On Break, and a shift planner that handles overnight shifts. Refresh it and it forgets everything, which is the correct behaviour for a UI prototype and the wrong behaviour for the product — that's exactly why the real thing ships as source code you run yourself.

If your operation is patchwork — one tool for bookings, WhatsApp for staff, a spreadsheet for shifts — that's the gap this is aimed at. Test the demo, then ask the vendor the persistence and concurrency questions above before you commit.

Have you evaluated restaurant management platforms? I'm curious which ones let you run the front end before you talk to sales.

Top comments (0)