The Veloce-Engine Page Promises "Automated Shift Planning." I Ran the Demo and It Just Stores What You Type.

Every product page on WorkflowAlpha.ai ships a working interactive demo. That's the whole sales pitch: test before you pay. So I tested the one on the Veloce-Engine page — a $199.99 one-time B2B platform for food & beverage operations — and then I read the JavaScript behind it.

The marketing copy is ambitious:

Automated Shift Planning — Build schedules in minutes, not hours. The system considers availability, role requirements, and staffing levels to suggest optimal schedules.

I wanted to know what "considers availability" looks like in code. Here's what I found.

How I tested it

I pulled the live page, extracted the demo's <script> block (8,275 bytes, 186 lines), and executed the verbatim script under Node v24 with a minimal DOM stub — no re-implementation, no paraphrasing. Then I drove the real handlers: the reservation form's submit listener, the staff status toggle, the "Add" shift button, and the two delete functions. The outputs below are what the script actually did.

What the demo actually does

It's three in-memory arrays and eight functions:

let reservations = [...];   // 4 seeded rows
let staff = [...];          // 5 seeded rows
let shifts = [...];         // 5 seeded rows
let nextResId = 5;
let nextShiftId = 6;

renderReservations, updateStats, renderStaff, renderShifts, deleteReservation, updateStatus, toggleStaffStatus, deleteShift.

That's it. No fetch. No XMLHttpRequest. No localStorage. Nothing leaves the page, and nothing survives a refresh.

Finding 1: There is no shift planner. There's a shift list.

The page says the system "considers availability, role requirements, and staffing levels to suggest optimal schedules." I searched the script for suggest, availability, optimal, role, and level. Zero hits — the only match was in the HTML marketing copy.

The entire shift feature is:

addShiftBtn.addEventListener('click', function() {
    const staffId = parseInt(shiftStaffSelect.value);
    const start = document.getElementById('shift-start').value;
    const end = document.getElementById('shift-end').value;
    if (staffId && start && end) {
        shifts.push({ id: nextShiftId++, staffId, start, end });
        ...
    }
});

That's a form that appends a row. It has no notion of a staff member's availability, no notion of which roles are required for a shift, and no notion of how many people should be on the floor. You pick a name from a dropdown and two times from two time inputs, and it saves.

Finding 2: I scheduled one person four overlapping shifts

Sarah Miller (staff id 2) came seeded with one shift, 11:00–19:00. I clicked "Add" three more times with times 22:00–06:00, 11:00–19:00 again, and 15:00–23:00.

Result:

Sarah Miller now has 4 shifts: 11:00-19:00, 22:00-06:00, 11:00-19:00, 15:00-23:00
no conflict/overlap check anywhere in the demo JS

Four shifts, two of them identical, three of them overlapping. All four render. Nothing warns. If this demo is meant to be "a live demo of the dashboard your team will use every day," then the real product's overlap detection — if it has any — is not represented here.

Finding 3: Overnight shifts are accepted with no validation

I added a shift 22:00 → 06:00. The only guard in the handler is if (staffId && start && end) — a truthiness check on the raw strings. So an end time earlier than the start time passes cleanly:

shifts now: 6 | last: {"id":6,"staffId":2,"start":"22:00","end":"06:00"}
rendered cell: 22:00 – 06:00 -> accepted with zero validation

For a restaurant running a late kitchen, overnight shifts are normal. The demo doesn't care either way — it just concatenates the two strings with an en-dash. Whether 06:00 means "tomorrow 06:00" is left entirely to whoever reads the screen.

Finding 4: Party size is not clamped in the JavaScript

The form markup does declare bounds:

<input type="number" id="res-party" required min="1" max="20" value="2" ...>

But the submit handler reads it with a bare parseInt and no clamp:

party: parseInt(document.getElementById('res-party').value),

I submitted 99. The stored value was 99. A min/max on a number input constrains the spinner and typed entry — it is not a server-side or script-side guarantee, and the script adds none of its own.

Finding 5: The one defensive branch in the whole file

renderShifts does this:

const s = staff.find(st => st.id === sh.staffId);
...
<span class="mock-shift-name">${s ? s.name : 'Unknown'}</span>

I injected a shift pointing at staffId: 424242 and it rendered as "Unknown" instead of throwing. That's the only place in the script that guards against a missing reference — which is reasonable, and also tells you the rest of the code assumes its data is always consistent.

Finding 6: The staff status toggle is a fixed 3-cycle

Clicking a staff member's status pill runs:

const order = ['online', 'break', 'offline'];
const idx = order.indexOf(s.status);
s.status = order[(idx + 1) % order.length];

Verified by clicking Sarah Miller four times: online → break → offline → online → break. It's a modulo cycle, not a state machine — there's no "on a call", no "clocked out", and no way to set a status directly.

Finding 7: Deleting everything works, and the ID counter never resets

I deleted all four reservations. The empty-state message appeared (display: block) and the stat cards went to 0 / 0 / 0. Then I added one reservation and it got id 7 — the nextResId counter is a module-level variable that keeps climbing across deletions, so IDs are not reused and are not dense. If you ever export this data, expect gaps.

The part that actually holds up

I want to be fair to the demo, because some of it is genuinely well-built:

• The empty-submit guard works. With shift-start and shift-end blank, clicking "Add" did nothing — 5 → 5 shifts. The truthiness check does its job.
• The status dropdown is complete. All four lifecycle states are selectable: Pending / Confirmed / Seated / Completed, and switching them re-renders and updates the "Confirmed" stat correctly.
• The stat cards are real, not hardcoded. After deleting everything and adding one reservation, they read total=1, pending=1, confirmed=0. The page's static HTML ships with 0 0 0 0 in those cards; the JavaScript overwrites them on load. They track the data.
• The seeded data is coherent. Maria Garcia / James Wilson / Aisha Patel / Carlos Ruiz map to the four statuses, and the five staff members map to the five shifts one-to-one. Someone thought about the initial state.

So what is this demo, honestly?

It's a CRUD front-end prototype with seeded data — a credible sketch of what a reservation and staff dashboard could look like, and a genuinely useful thing to click through before spending $199.99. It is not, and does not claim to be in the demo itself, the "automated shift planning" engine described in the feature card above it.

That gap is worth naming, because it's the difference between what a buyer tests and what a buyer buys. The demo proves the interface is real. It does not prove the automation is.

If you're evaluating Veloce-Engine, the honest read is: the reservation and staff views are shaped and working, the shift planner is currently a list you type into, and you should ask specifically what the deployment's scheduling logic does before you rely on it.

---

Try it yourself

Live demo + product page: https://reggiebro.github.io/WorkflowAlpha.ai/veloce-engine/

Add a reservation, toggle a staff member's status three times, and try scheduling one person into two overlapping shifts. It takes about sixty seconds and it's the fastest way to see exactly what you'd be buying.

Buying Veloce-Engine

$199.99 one-time license. Custom deployment on your infrastructure is included in the license fee.

• PayPal: send to [e-mail] (add a note with what you're buying; I confirm in the inbox)
• Crypto: 0x078fE079A9440631Bc6AD722D7143dC382b4ea4f on Base (ETH / USDC / USDT)
• Western Union / MoneyGram — available on request

Questions before you buy: [e-mail]