Preshift Rota

The rota built by finance people who have run hospitality floors. A joint venture between Williams, Stanley & Co. and Preshift.

Every rota tool on the market answers "who is working when". Preshift answers the question an operator actually cares about: "what will this week's labour cost me against what I will take, and is it legal". It builds the rota from the sales forecast, costs every shift the way payroll will, blocks anything that breaks UK employment law, and hands finance a ready-to-post labour accrual so the P&L carries true labour before payroll has even run.

What's new: week of 2 November 2026

A one-page card for the team. Read it in two minutes, then open the app and try each item once. Past cards live in docs/WHATS_NEW.md.

For	What changed	Why it matters
GMs	Coaching for this draft: while a week is a draft, a panel under the decisions reads the site's last four weeks of rotas, takings and sales forecast. Again marks a mistake repeated (a day over the labour target again after running over before, a weekday that keeps taking 10% or more above or below forecast, a role stacked over demand on the same hours as before). Tip marks something to fix in this draft (three chefs on at once when the forecast needs two, a role all starting at the same minute, a day with more hours than its usual sales per labour hour needs). Keep doing marks a day pulled back inside target. Gone once the week is published; switched with Coach.	The same mistakes cost the same money every week until someone points at them while the rota can still change. This points at them before publish, not at month end.
GMs	By person: copy and paste a shift (Copy in the editor, or Ctrl+C), shift types set once per site and picked from Build from, cover against demand on each day heading, live while dragging, and key dates along the top of every rota view.	The rota is written faster, and the cover gap is seen on the grid it is fixed on.
GMs	Day notes: several per day by type and time, weekly if needed, and told to the team in the staff app and on the kiosk when marked for them.	The big booking, the delivery and the road closure reach the people working that day, not just the manager who wrote them down.
GMs	Weddings, buyouts and functions on the demand, from Tripleseat, SevenRooms or by hand on Calendar. Confirmed events add their own team by guest ratio; exclusive hires take public trade out; provisional ones move nothing.	An event day is staffed for the event, not guessed from a normal Saturday, and it does not distort what the forecast learns.
GMs	A week that is over reads as traded: takings, clocked labour, labour % and the budget on what was taken, with the full P&L setting clocked labour against the rota by day.	The review of last week starts from what happened, not from the plan.
Everyone	Ask Shifty is the one place to ask (Ctrl K); the Tell Preshift bar has gone. A narrated walkthrough opens from How to, Support and the staff app.	One place for questions, and a how do I answered by seeing it done.

The test for this week: Before you publish next week, open Coaching for this draft at your site and deal with every Again card: fix it, or write down why it stays. At the weekly review each GM names one card they acted on and what it changed on the labour line.

Feature list

Area	What it does	Where
Demand-led build	Turns hourly forecast sales and covers into headcount per role (sales per labour hour or covers per person, with floors and caps), then fills the gaps peak-first, cheapest legal person first, and trims overstaffed edges. Gaps it cannot fill legally are reported as a hiring or cross-training signal.	src/engine/demand.ts, src/engine/autoschedule.ts
True cost per shift	Gross pay, holiday accrual (12.07%), employer NI at 15% over the £96 weekly threshold, auto-enrolment pension on qualifying earnings, guaranteed contracted hours. On-costs are worked on the whole week then spread over shifts, so the rota reconciles to payroll.	src/engine/cost.ts, src/engine/ukRates.ts
Marginal cost	The shift editor shows what a shift adds to the week, not a naive rate x hours. Someone on guaranteed hours costs nothing extra; someone already over the NI threshold costs 15% more than the headline rate.	src/ui/ShiftEditor.tsx
UK compliance	Working Time Regulations breaks, 11 hour daily rest (across week boundaries), weekly rest, 48 hour average without opt-out, young worker limits (8h/day, 40h/week, 30 minute break, 12h rest, never between midnight and 04:00), night workers (the 8 hours in 24 average and the health assessment offer), minimum wage by age, double booking, leave, availability, training. Blocking issues stop publication.	src/engine/compliance.ts
Live labour %	Forecast sales, loaded labour, labour % against the site target, pound variance, SPLH, by day and week.	src/engine/metrics.ts, src/ui/PnlStrip.tsx
People	Employee records: details, employment dates, roles, contract and pay, right to work with the copies of the documents checked, availability and leave. Each record is checked before it reaches the rota: right to work missing or expired, checked with no copy held or no date recorded, pay below the legal minimum, upcoming birthdays that move the minimum wage band, salaried pay that falls below minimum wage at maximum hours, under 18 opt-outs, auto-enrolment eligibility. Starters and leavers are pro-rated in cost, kept off the auto-build outside their dates, and exported for payroll.	src/engine/employees.ts, src/ui/PeopleView.tsx, src/ui/EmployeeEditor.tsx, server/routes/documents.ts
Holiday	Entitlement balances per person for each company's leave year: 5.6 weeks (or the contract) earned evenly for fixed hours staff, 12.07% of hours worked for irregular hours staff (paid travel between sites included), from approved clocked time where it exists and the rota otherwise. Taken and booked leave, carry over, opening balances at go-live, and per-day hours. Flags overbooking, unused leave near year end, and leavers' final holiday pay. The untaken balance is valued as the holiday pay provision, with employer NI, to match the balance sheet accrual.

Design

The product is meant to read like management accounts, not like a rota app, in Williams, Stanley & Co. colours: WS navy (#003359) on white over a pale blue gradient, ledger rules and double rules under totals, set in Geist with Geist Mono for figures and labels. Beyond the navy, colour is reserved for money and the law: teal inside budget, coral over budget or blocked, gold to review, each checked for colour-blind separation and always shown with a label or mark. Roles and departments are told apart by position and label, never by colour, so anything coloured on screen is something to act on.

Specification

The detail behind the feature list. Every figure here is in the code; if they disagree, the code is right and this section is out of date.

Labour costing (src/engine/cost.ts, src/engine/ukRates.ts)

Parameter	2026/27 value
National Living Wage (21+)	£12.71 an hour
NMW 18 to 20	£10.85 an hour
NMW 16 to 17 and apprentice rate	£8.00 an hour
Employer NI	15% above £96 a week (secondary threshold)
Auto-enrolment pension	3% employer on qualifying earnings £120 to £967 a week; trigger £192 a week; ages 22 to 66
Holiday accrual	12.07% of hours worked for hourly and irregular-hours staff (5.6 / 46.4)
Employment Allowance	£10,500 a year, one claim per connected group

On-costs are calculated on the whole week, then spread across that week's shifts, so the rota total reconciles to payroll. The shift editor shows marginal cost: what the shift adds to the week.

Compliance rules (src/engine/compliance.ts)

Blocking issues stop publication and are refused by the assistant. Warnings are shown and allowed.

Rule	Severity
Minimum wage for the person's age band	Block
Rest breaks under the Working Time Regulations; 30 minutes over 4.5 hours for under 18s	Block
Under 18s: 8 hours a day, 40 hours a week	Block
Under 18s between midnight and 04:00, which the hospitality exemption never allows	Block
Double booking across any site, on leave, outside employment dates, right to work missing or expired	Block
11 hours daily rest, checked across week boundaries; 12 hours for under 18s	Block
Weekly rest: one clear day in the rota week, two for under 18s	Block
Not enough time to travel between two sites' shifts, by the TfL journey time or estimate	Block
Under 18 working between midnight and 04:00, which the hospitality exemption never covers	Block
Under 18 working between 22:00 and 06:00 (allowed in hospitality only when supervised, with compensatory rest)	Warn
Outside stated availability, or not trained for the role	Warn
Move between sites within 10 minutes of the journey time, or sites with no postcode set	Warn
Over 48 hours without an opt-out (must average 48 or less over 17 weeks)	Warn
Over the person's own maximum weekly hours	Warn
Below contracted hours on a full week (the gap is paid regardless)	Warn
Night worker opted out of the 48 hour week averaging over 8 hours in 24 across 17 weeks (the opt-out does not cover night work)	Warn
Night worker with no current health assessment offer on the personnel file	Warn

Rest breaches, and only rest breaches, can be overridden by a person who may publish the rota at that site, with a reason of at least 15 characters (why, and the compensatory rest the person gets). The breach then publishes as a warning carrying the manager's name and reason. An override covers that breach exactly as it stood: move either shift, or change the days worked, and it blocks again. System keys cannot override, the auto-build and the rota assistant never rely on one, and every override, withdrawal and publish through one is in the audit log. The Sites view shows overrides per site for the selected week and the three before it, with a group total and a "Recurring" tag on any site that overrode in three of those four weeks (overrideTrend in src/engine/compliance.ts). A daily rest override counts at the site of the shift worked short of rest, a weekly one at the person's home site. Routes: GET, POST /v1/rota/overrides, DELETE /v1/rota/overrides/:id.

Demand-led build (src/engine/demand.ts, src/engine/autoschedule.ts)

• Input: hourly forecast net sales and covers per site, from PUT /v1/forecast.
• Per role and site: sales per labour hour or covers per person per hour, a floor while open and a cap.
• Fill order: peak hours first, cheapest legal person first, own-site team before cross-site cover.
• Edges trimmed where overstaffed. Unfillable gaps are reported as a hiring or cross-training signal.

Rota assistant (src/ai/, server/routes/assistant.ts)

• Claude drafts changes by calling the engine's own tools; it never writes shifts directly.
• The server route accepts one fixed model, caps output at 16,000 tokens and refuses streaming.
• The organisation's key is held server side, shown only by its last four characters.
• The GM sees labour % before and after, the changes and the trade-offs, then applies or discards.

Finance outputs (src/engine/journal.ts)

• Labour accrual journal per entity, by role nominal and site tracking category.
• Basis: approved actuals when available, otherwise the rota (basis=rota|actual|auto).
• Format: JSON or Xero manual journal CSV.
• Intercompany recharge posted on both sides where a person works at another company's site, checked to agree before posting.

Messages and channels (src/engine/messaging.ts, server/messaging.ts, server/routes/messages.ts)

Item	Specification
Record	Every message, announcement and rota notice is stored in Preshift, one direct thread per person, with read times. Channels only carry it. Kept 13 months by default, longer up to 72 where the client sets it in its retention periods under Privacy, at most 5,000 per organisation, oldest first out.
Who	Managers with rota.edit or team.manage at the person's home site read and send; announcements need rota.publish at the site. A key with no person behind it is refused. Staff see their own thread and announcements to them only, never delivery details.
Rota notices	Sent on publish to each person whose published shifts for the week differ from what they were last told, including being taken off. A channel failing never stops the publish.
Staff channels	WhatsApp (Meta Cloud API v21), text (Twilio), email (Resend). One notice goes by the first of the person's choices that works. WhatsApp and text need the person's own number and consent, given in the staff app; a new number needs consent again; STOP on WhatsApp withdraws it.
WhatsApp	Free text within 24 hours of the person's last message, otherwise the approved template named in Settings with the message as its one body variable. Replies need Meta's x-hub-signature-256 with the app secret, are taken once by message id, text only, and only from a number someone agreed from. Delivery and read reports update the message.
Quiet hours	Default 22:00 to 07:00 London time, per person. Non-urgent messages are held and sent by the quarter-hourly run (/internal/webhooks, or the daily /internal/dispatch) once the hours end. Urgent ones go at once.
Team channels	Slack incoming webhooks (hooks.slack.com) and Teams Workflows webhooks (*.logic.azure.com, *.api.powerplatform.com, *.webhook.office.com) per site or for every site. Notices name the person and site with a link, never message text.
Keys	Saved under Settings in the settings store, never in organisation data; shown by their last four characters. Refused in the demo.

Time, clocking and the staff app

Item	Specification
Phone tags	A secure NFC tag (NTAG 424 DNA) at a site. Staff touch it with their own phone, which opens the staff app at an address the tag writes on every read: its serial and read counter encrypted under one key, and a MAC under another (Secure Unique NFC, NXP AN12196). The staff session proves who and the tag proves where, so no location is needed. A read is accepted once and only while its counter is above the last accepted, so a copied link is refused once anyone has tapped since. A tag's first read fixes its serial; another chip with the same keys is refused. Only at the person's shift, home or cover sites. Keys shown once when the tag is added and kept in the settings store. Entries carry method tag.
Geofence	Per site. Fix accuracy is allowed on top of the radius, up to the radius again. Fixes worse than 250 m are refused.
Card taps	A reader fixed on site under its own API key is not location checked, and may send the time of a tap it held offline. A card read on a signed-in tablet or phone needs the device inside the geofence, like any device clock. Repeat reads of one tap are ignored. A tap during a break ends the break.
Clock times	A clock from a person's screen is timed by the server: a time sent more than two minutes off is refused (time_set_by_server), so no one can clock a colleague in for a shift they never started. Missed clocks go in as manual entries for approval.
Personal details	Date of birth, right to work evidence and expiry, holiday record and card number go only to those who manage the team or read HR at the person's site. Others, such as a supervisor, see whether someone is under 18 and whether their right to work is checked, with an expiry only when it falls within the next eight weeks of rota.
Phone clocking	By location: requires the site's geofence, for clock-in and clock-out, and is refused at a site with no fence. By phone tag: no location needed.
Breaks	Not location checked. Recorded as {start, end} and set unpaid minutes at clock-out. Clocking out ends a running break.
Approval	Manager approval, rota against clock by person, period locked once sent to payroll.
Pay periods	Per company payroll: weekly, fortnightly, four_weekly, monthly, last_friday. Default weekly, Monday to Sunday, paid Friday, due Tuesday 12:00. Paydays and cutoffs on a non-working day move to the working day before; a cutoff that would land inside the period moves to the first working day after it. Lock rota needs at every site the period reaches; time cards need the rota locked and ; passing needs , the period ended and every card approved. See .

Access and security

Item	Specification
Manager sessions	12 hours, HttpOnly cookie, checked against the database on every request.
Staff sessions	30 days, separate signing key, never accepted by the manager API.
Passwords	scrypt hashes. Five wrong attempts lock the account for 15 minutes.
Password reset	Single-use email link valid 30 minutes, at most three emails an hour per account, token after #. Admin-issued link valid 24 hours.
Staff invite	One-time link valid 7 days; a new invite resets a forgotten staff password.
Roles	Admin and member. At least one admin per organisation; nobody can remove themselves.
API	Scoped API keys, per-organisation tenancy, OpenAPI docs at /docs. TeamPay webhooks HMAC signed.

Platform

Item	Specification
Stack	TypeScript throughout. React 18 and Vite for the web and staff apps; Fastify 4 for the API.
Storage	Postgres (Neon) via PRESHIFT_DATABASE_URL; in memory without it. Never reads DATABASE_URL.
Payroll	TeamPay, through an idempotent, retrying outbox; daily Vercel Cron retry.
Hosting	Vercel Build Output API: marketing site, one Node API function, app served to signed-in people only.
Quality	1360 tests across 138 files (clocking by phone tag, the night average from the first week, day totals by trading day, a new sign-up's first steps, night workers and their health assessment offers, trading round the clock and the cut call past midnight, open shifts kept out of locked pay periods, pay calendars and the pay period close, customers, Xero journal posting, open shifts offered cheapest first and approved automatically, shifts going in rounds, messaging and channels, under 18s at night, message retention, signing the written statement and handbook in the staff app, tips and payslips in the staff app, tips through payroll, pay premiums, escalation and Seen it, shift reminders, no-shows and adoption, labour cash calendar, phone push, wellbeing and Hospitality Rewards, pricing, support desk, staff requests, swaps, open shifts, notifications and the managers' morning email, engine, sign-up and billing, staff login close review, forecasting from takings, forecast accuracy, staff app invitation emails, clocked against rota, cut call, compliance pricing, tronc, prime cost, retention, demo trading history, clients and onboarding, access and permissions, rota assistant and chat, travel, reports, right to work documents, HR, GDPR, UI rules, assistant, API, clocking, breaks, staff, payroll, privacy, demo, Postgres store, reset, MCP connector). CI typechecks and tests every pull request and every push to main.

Running it

npm install
npm run dev      # API on :8787, web app on http://localhost:5173, API docs on /docs
npm test         # engine, UI rules, assistant and API tests
npm run build    # typecheck and production build
npm run test:e2e # browser checks of the management bar and iPad touch (Playwright), against a local dev server

To run the browser checks against a deployed site instead, set PRESHIFT_E2E_URL to its address and PRESHIFT_E2E_EMAIL and PRESHIFT_E2E_PASSWORD to an admin account there, or set PRESHIFT_E2E_DEMO=1 to go in through its public demo with no account (for example PRESHIFT_E2E_URL=https://preshift.williamsstanley.co PRESHIFT_E2E_DEMO=1 npm run test:e2e). They only navigate; they never build, clear, publish or save.

The Live checks workflow (.github/workflows/live.yml) does exactly that against https://preshift.williamsstanley.co after every successful production deployment, nightly, and on demand from the Actions tab. A failure opens a "Live checks failing" issue, or adds to the open one, and the issue closes itself when the checks pass again. Set the PRESHIFT_LIVE_URL repository variable to point it somewhere else.

Locally, sign in as [email protected] with password preshift-dev-password. That account only exists when the API runs without a database, and is never created on the live system. To try the labour programme's sign-offs, act as Sam Okoro, the WS client partner, from the demo people. The demo carries twelve weeks of till history, so the forecast model and accuracy work straight away.

Evaluating the rota assistant

src/ai/evals/cases.ts holds 16 realistic requests on the demo group, from "build the week" to "put Chloe on while she is on leave" (which must be refused) and "check, but change nothing". Each is graded on the rota the assistant leaves behind, with separate pass/fail checks: legal, history untouched, cover kept, labour at target, the instruction met, and a short plain note. Every case has a reference solution that must pass and a do-nothing answer that must fail unless doing nothing is right; npm test proves both, so the grader is trusted before any money is spent.

To run it against Claude, on a machine with a Claude API key (ANTHROPIC_API_KEY or an ant auth login profile; this is a developer tool, separate from the key the app keeps in Settings):

npm run eval:assistant -- --reps 1                       # every case once, roughly $5 to $15
npm run eval:assistant -- --cases follow-up --reps 3     # one case, three times

It writes eval-results/<time>/ with summary.md (pass rates with 95% intervals, per case and per check, and the cost), results.jsonl, errors.jsonl (API errors, timeouts and wrong-model runs, never counted as wrong answers) and every conversation under transcripts/. Run it before any change to the assistant's prompt, tools or model, and compare the summaries.

Sign in, people and settings

Everything about access is managed inside the app, under Settings. Nothing is configured in environment variables.

• First run. On a system with no accounts yet, the sign-in page offers "Create the owner account". Whoever completes it first becomes the owner (an admin), so do it straight after the first deploy. It can only ever happen once, enforced in the database.
• Who can sign in. Separate from the Staff section, which holds staff records. Admins add accounts with a first password and a role, reset passwords, change roles and remove people. Members use the app but cannot manage access. Every organisation keeps at least one admin, and nobody can remove themselves.
• Rota assistant. An admin saves the organisation's Claude API key. It is kept on the server, shown afterwards only by its last four characters, and used only for the assistant's own requests (one model, capped output). Set a monthly spend limit on it in the Claude Console all the same.
• Your password. Anyone can change their own; doing so signs out their other devices.

Accounts, password hashes (scrypt), the session signing key and the Claude key all live in the Preshift database. Sessions last 12 hours in an HttpOnly cookie and are checked against the database on every request, so suspending someone or resetting their password takes effect at once. Five wrong passwords lock an account for 15 minutes. The web app carries no API key: it calls the API with the session. On Vercel the app's files are served by the API function only to signed-in people.

An account is how a person signs in; what they may do is their access record on the Access tab, found by the same email. People are invited there, and set their own password from the invitation link (seven days, single use) on the sign-in page. "Reset password" on the Access tab ends the old password and every session at once, and sends a link, valid a day, to choose a new one. Nobody ever chooses or learns another person's password. Someone who signs in with an account but no access record keeps full access in the account's own organisation, as every account had before roles, and the Access overview lists them as Fix now until they have one.

One person can work in several organisations, as a Williams, Stanley & Co. manager does across clients: one account, one password, one authenticator, and an access record in each organisation. Each organisation controls only its own record of them.

• Someone who already signs in to Preshift accepts another organisation's invitation by signing in with the password they have. The link never sets a new one, since whoever holds it, including an inviter when email is not set up, would then hold every organisation the account opens.
• The header switches between their organisations. The authenticator code entered once a session counts in all of them, and sign-in returns them to where they last worked.
• The account belongs to its home organisation, the one where it was made. Only there can its password or authenticator be reset, and a reset of an account that opens other organisations is only ever emailed, never handed over.
• Anywhere else the organisation suspends or removes the person's access to itself, which leaves their other organisations, and their sessions there, as they were.
• No organisation learns which others a person works in.

Roles that touch pay, payroll, the journal, settings or access need an authenticator app. After signing in, the app asks for its 6-digit code before switching those rights on for the session, and walks anyone without one through setting it up (QR code, then ten single-use recovery codes, shown once). The first owner sets theirs up before inviting anyone. Authenticator secrets are encrypted with a key kept in the database, or, stronger, with PRESHIFT_SECRET_KEY (64 hex characters, openssl rand -hex 32) so the key never sits in the database it protects; never change it once people have enrolled. The demo's enrolled people share the published secret JBSWY3DPEHPK3PXPJBSWY3DPEHPK3PXP locally, never in production.

Email goes through Resend once someone with settings rights saves a Resend key, a from address on a verified domain and the app's address under Settings. Invitations and resets are then emailed to the person and the link is never shown to whoever sent it, so nobody else can set their password; until then the link is shown once, to hand over in person. Two rules stop a reset becoming a takeover. Resetting someone's password or authenticator, or sending them a fresh invitation, needs the authority to give them every role they hold: an operations director can reset a GM, never the people manager or the owner, and Williams, Stanley & Co. never changes the accounts of a client's own people. And the link for anyone holding rights that move money or reach confidential records (pay, payroll, locking, the journal, access, settings, cases, staff data requests) only ever goes to their own email, never handed over, even to the owner. People who forget their password use "Forgot your password?" on the sign-in page: a single-use link, valid for 30 minutes, emailed only once email is set up. Its reply never says whether an account exists, and one account gets at most three emails an hour; invitations are capped at three sends an hour too. Every link's token sits after #, so it never reaches a server log, and only its hash is kept.

What became of each email shows on the Access tab against the person: sent, delivered, delayed, bounced, marked as spam or failed. Resend reports it to a webhook at /v1/integrations/resend/webhook/<organisation>; Settings shows the address to give Resend and takes its signing secret (whsec_...), and a report without a valid signature from the last five minutes is refused. Without the webhook, "Check now" on the person asks Resend. A bounce, a spam complaint or a failure goes on the Access overview with the receiving server's reason until it stops mattering (the invitation is accepted or withdrawn, or the person signs in after the reset), and the person's panel offers to hand a new link over instead of emailing it again. Preshift keeps who each email went to and its reports for 180 days, never its content or link, and does not track opens or clicks.

Known limit: a reset link is built on the home organisation's saved app address and sent through its Resend account, so the home organisation's admins are trusted with the account; a person who works for several clients is best made at home in the organisation they belong to.

The demo runs a small group: West End Dining Ltd (Marylebone and Fitzrovia) and East Canteen & Kitchen Ltd (Shoreditch), with realistic teams, rates and forecasts, against a TeamPay simulator. A few people cover sister sites, and one Shoreditch bartender covers Marylebone, which is a cross-company recharge. Choose an entity and site in the top bar, or leave both on "All" for the group view, and press "Build" to generate the week. The rota assistant and the Payroll tab work on one site, so they appear once a single site is selected. On the Payroll tab: set people up in TeamPay, simulate clocking, approve, send hours, run payroll. Set the TEAMPAY_* variables to connect to real TeamPay and PRESHIFT_DATABASE_URL for Postgres; see docs/API.md, which also covers the Vercel deployment.

Business set-up

Organisation, then Set-up, holds the business the rota runs on. It needs settings.manage, and so an authenticator (src/ui/SetupView.tsx, rules in src/engine/setup.ts, routes in server/routes/setup.ts):

1. Companies: registered name, company number, PAYE reference, and an intercompany code once there is more than one.
2. Sites: company, opening hours, loaded labour target, Xero tracking category.
3. Roles: starts from the standard hospitality roles, each mapped to a wages nominal code.
4. Trading and staffing: a typical week's net sales per day and average spend for each site, and covers or sales per person per hour for each role. Takings start blank on purpose.
5. Review and save: weekly labour budget per site; anything incomplete blocks the save.
6. Team: paste people from a spreadsheet or payroll export (Name, Roles, Rate or salary, Date of birth, Contracted hours, Start date, Right to work checked on). Each goes through the starter route, exactly as from People, so each is set up in TeamPay. Rows with problems are held back, pay below the minimum wage band is flagged, and anyone without a right to work check is added but cannot be rostered until it is recorded.

A new live system starts on the sample group. Admins see a banner saying so, and set-up offers "Remove sample data" while nothing real exists: no own companies, sites or people, nothing in payroll, no clocked time, no staff logins, no HR records or data requests, and nobody real with access tied to a sample site. Clearing also removes the sample's fictional people and HR files. After that it is refused, and the sample can only be edited. Each site's typical week forecasts the next eight weeks, and the build fills any later week on demand. Figures from a sales system replace it week by week and are never overwritten. A company, site or role that people, rotas or clocked time still use cannot be removed.

Sites can trade past midnight, closing as late as opening time the next day, or open round the clock. The trading day then runs on: a bar open 16:00 to 02:00 has Friday's demand, staffing and forecast run to 02:00, with the hours after midnight stored against Saturday's date (as a till or sales feed reports them) and read back as Friday night. The auto-build rosters shifts that finish at close, and each night's forecast still adds back to the day. Every daily total does the same: labour % by day, the rota's day P&L, the timeline's sales curve, takings entry, scorecards and forecast accuracy count the hours after midnight to the night they belong to, as the shifts already are. A day's takings keyed in or sent by the till are taken as the till's trading day; only hourly till figures are moved.

Self sign-up and billing

A business can start on Preshift without a set-up call. Switch it on with PRESHIFT_SIGNUP=1 once the first organisation has email set up under Settings, since its Resend account sends the confirmation links. The sign-in page then offers "Start a free trial", and the marketing site links to it.

1. The visitor gives their business name, their own name and their work email.
2. A single-use link goes to that inbox, valid 24 hours. Nothing is made until it is used, so nobody can claim someone else's email. If the email already has an account, the inbox is told to sign in instead and the page says exactly the same, so the form never reveals who is a customer. At most three emails an hour per address, ten sign-ups a day per visitor address and 200 a day in total.
3. Opening the link, they choose a password. A new empty organisation is made, named after the business, with them as its owner, on a free trial (PRESHIFT_TRIAL_DAYS, default 14), and they land in Set-up. Like any owner, they set up an authenticator before settings and billing open.

Pricing

Published on the marketing site, charged by Stripe and quoted on the Billing page from one source, src/engine/pricing.ts:

	Per site a month, before VAT
Sites 1 to 5	£119
Sites 6 to 20	£99
More than 20 sites	Group plan, agreed with us

• Per site, everything included, never per member of staff: hospitality hires seasonally and turns staff over fast, and a per-head price charges for the flexibility a rota exists to manage.
• Graduated: each site is charged at its band's rate, so adding a site never makes the others dearer. Eight sites are 5 x £119 + 3 x £99 = £892 a month.
• Yearly is ten months' price for twelve. 14 days free, no card, month to month after.
• Founding operators: 30% off for 24 months, through a Stripe promotion code on the founding coupon.
• Williams, Stanley & Co. clients: within their WS fee, never billed here.
• TeamPay bills payroll itself; the rota assistant runs on the customer's own Claude key.

To change a price, edit src/engine/pricing.ts, bump its version, update the PRICING block in site/main.js and the figures in the page copy (server/pricing.test.ts fails until they agree), then run npm run stripe:prices and set the new price ids. Existing subscribers stay on the price they bought until moved.

Setting up Stripe

STRIPE_SECRET_KEY=sk_test_... npm run stripe:prices creates the product, the monthly and yearly graduated prices and the founding coupon from src/engine/pricing.ts (add -- --dry-run to see what it would do; run again safely, it reuses what exists). Set STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET, and the STRIPE_PRICE_ID and STRIPE_PRICE_ID_ANNUAL it prints, and point a Stripe webhook at /v1/integrations/stripe/webhook (events listed in docs/API.md). Organisation, then Billing:

• The page quotes the organisation's own sites band by band, with VAT, monthly or yearly. Subscribe opens Stripe Checkout for those sites (the sample group's never count, minimum one; above 20, a group plan instead). Trial days left carry over, so paying early costs nothing. Checkout collects the billing address and VAT number, and accepts promotion codes.
• Manage billing opens Stripe's customer portal: card, VAT invoices, company details, cancelling.
• When sites are added or closed, one button brings the sites paid for into line; Stripe prorates it.
• The page shows the standing, renewal date and last invoice. Owners see a banner in the last week of the trial, and when a payment fails.

Standing	When	What works
Billed by WS	No billing record (the first organisation and every WS client), or moved to a WS engagement and past the date it took effect	Everything, always
Free trial	Trial days left and no subscription in force	Everything
Subscribed	Stripe reports active or trialing	Everything
Payment failed	Stripe reports past_due and is retrying the card	Everything, with a banner
Lapsed	Trial over with no subscription, or cancelled, unpaid or expired	Every read, Billing, your profile and authenticator, GDPR requests. Every other change is refused with 402 billing_required until someone pays

Nothing is paused on a system without Stripe configured: nobody is cut off who has no way to pay. Stripe's events are believed only with its signature over the exact bytes, from the last five minutes, and are applied to the organisation Preshift recorded when it made the Stripe customer, never one named in the event. Late or out-of-order events cannot undo a newer status. Preshift keeps the customer and subscription ids, status, sites paid for and the last invoice's amount and link: never a card. Demo sandboxes are never billed.

Customers

Organisation, then Customers, is the commercial view of self sign-up: who signed up, who reached a published rota, who converted, what that is worth and who needs a call this week. It lists every organisation with a billing record (self sign-ups), never those billed under a WS engagement, which stay under Clients.

• Who sees it. The WS customer operations role (ws_customers, permission customers.view), with an authenticator, working in the system's own organisation, the first one. A WS client partner there grants it on the Access tab. Keep it to the fewest people: it is the one screen that shows every customer at once. Granted inside a customer's organisation it shows nothing, so no client can grant itself a view of the others. Never an API key.
• What it shows. Counts and billing standing, and the owner's name and email so someone can call them. Never a customer's staff, pay or personnel data.
• MRR is at list price before VAT, from src/engine/pricing.ts; founding and promotion discounts show on Stripe's invoices. Trial-to-paid is the share of customers whose trial has ended who are paying now.
• Read only, but for one action: paying, refunds and cancelling stay in Stripe. Every view is in the audit log.
• Not shown yet: sign-ups started but never confirmed (only their hashed links are kept).

Moving between card billing and a WS engagement

A customer can start on a card and be taken on by the firm, or leave an engagement and carry on by card. Both moves are recorded with who made them and when, in the customer's audit trail and the firm's, and show on Clients, Customers and the customer's own Billing page.

• To a WS engagement: Customers, "Move to WS engagement", for customer operations (permission customers.billing, with an authenticator). Stripe is told only to stop renewing the subscription (cancel_at_period_end): nothing is charged or refunded, so the customer never pays twice. They keep the period already paid for; from its end WS bills them, they show as Billed by WS, they leave MRR and nothing pauses them. With no subscription in force (a trial, or lapsed) the move takes effect at once. While it is pending, the customer's Manage billing is closed so the ending subscription cannot be renewed; once it has happened, it opens again for past VAT invoices. The move counts towards trial to paid, as a customer won, and Customers counts every customer taken on by the firm.
• To card billing: Clients, open the client, "Engagement ending: move to card billing", for the client's WS client partner once its owner has signed in, and only where Stripe is set up. The partner sets the date to subscribe by (14 days by default, at most 90). There is no free trial: the owner sees a banner and a Billing page asking them to subscribe by that date, after which changes pause until they do, exactly as for any lapsed card customer. The firm sends the engagement's final invoice as usual.
• Clients shows how each client pays Preshift, and warns the partner when a client also pays by card, so the firm does not bill it under the engagement as well. Customers warns if a customer on an engagement still has a Stripe subscription set to renew.

Public demo for prospects

The live system also hosts a public demo, kept apart from every customer. With PRESHIFT_DEMO=1, the marketing site's "Try the live demo" button opens /demo. Pressing "Start the demo" gives the visitor their own private copy of the demo group (a sandbox organisation) and signs them in with its full access. They can use the product as a customer would: build from forecast, edit shifts, compliance, people, HR, clock in at the site, payroll against the TeamPay simulator, the Close journals, GDPR, and the access controls on a fictional team, none of whom has an account. Every sandbox is wiped at midnight UK time.

Segregation and security controls, all in server/demo.ts and server/sandbox.ts:

• Identity. A sandbox is known by its id (sandbox-...), which only "Start the demo" creates. Its visitor account has an .invalid address and a random password nobody knows. Password sign-in, password changes and reset links all refuse sandbox accounts, demo accounts never count towards first-run owner setup, and integration keys cannot name a sandbox. A sandbox is reached only by its own visitor account, which works nowhere else, and no invitation into a sandbox can be accepted, so demo and customer accounts never mix.
• Routes. A visitor's session reaches only the routes marked true in SANDBOX_ROUTES. Anything else is refused, including any route added later: a test fails until each new API route is listed as allowed or refused, so every feature gets a deliberate decision about the demo. Refused: anything that issues an invitation or reset link or touches an authenticator, settings, the Claude and email keys, right to work copies (no real passport should go into a public demo), postcode and TfL lookups (they run on the live system's quota), and staff app logins (their emails are unique system-wide, so a visitor could otherwise find out whether an address is a customer's). The guard runs before a request body is even validated.
• Data. Each request loads only the caller's own organisation, as for every customer. Deleting data is a separate store operation that refuses any id that is not a sandbox, checked in code and again in the SQL. Payroll webhooks never create an organisation and answer an unknown one exactly as a bad signature, so they do not reveal which organisations exist.
• Payroll. Sandboxes always run on an in-process TeamPay simulator whose webhook secret is random per instance. Customers stay on real TeamPay, and the simulator-only routes return 404 for them.
• Capacity and cost. Opening /demo creates nothing; only a same-site form post does. Up to 500 sandboxes a day in total and 10 per visitor address (kept only as a keyed hash). The rota assistant is off unless PRESHIFT_DEMO_CLAUDE_KEY is set, then capped at 40 Claude calls per sandbox and 1,500 a day; set a monthly spend limit on that key in the Claude Console as well.
• Midnight reset. A visitor's session ends at midnight UK time even before clean-up runs. Vercel Cron calls /internal/demo-reset at 23:05 and 00:05 UTC (just after midnight in summer and in winter), and visitors starting the demo trigger it too. It deletes each sandbox with its visitor, staff logins, documents and counters. Needs CRON_SECRET.
• Kill switch. Unset PRESHIFT_DEMO and redeploy: nothing new starts, existing visitors are refused on their next request, and the reset still clears what they left.

Starting the demo replaces any Preshift session in that browser, which the start page says.

Locally: npm run dev:demo, then open http://localhost:5173/demo. The dev account still works.

Deployment (Vercel)

npm run build:vercel (set in vercel.json) writes .vercel/output with the Build Output API:

Path	What
/	Marketing site, from site/
/v1, /docs, /health	The API, bundled into one Node function from server/vercel.ts
/login, /auth/*	Sign-in, first-run owner setup and sign-out, served by the API function
/app/	Web app, served by the API function to signed-in people only (server/routes/web.ts)
/api/anthropic/v1/messages	The rota assistant's route to Claude, using the key saved in Settings
/internal/dispatch	Daily Vercel Cron retry of payroll changes TeamPay has not confirmed (needs CRON_SECRET)
/internal/webhooks	Vercel Cron every 15 minutes: webhook deliveries waiting on a retry, and messages held for staff quiet hours (needs CRON_SECRET, and a Vercel plan that allows cron jobs more often than daily)
/demo, /demo/start	The public demo's start page and the form post that starts a sandbox (with PRESHIFT_DEMO=1)
/internal/demo-reset	The demo's midnight reset, Vercel Cron at 23:05 and 00:05 UTC (needs CRON_SECRET)
/internal/digest	Managers' morning email of staff requests, Vercel Cron at 06:35 UTC, once a day per organisation with email set up (needs CRON_SECRET)
/internal/reminders	Shift reminders and not-clocked-in alerts, Vercel Cron every 5 minutes, each sent once (needs CRON_SECRET, and a Vercel plan that runs cron jobs more often than daily)
/v1/integrations/stripe/webhook	Stripe's signed billing events (with STRIPE_* set)

Set PRESHIFT_DATABASE_URL to a Neon database that belongs to Preshift and the API keeps its data in Postgres across cold starts and instances. Without it, data is held in memory and resets when the function cold starts: fine for a demo, not for customers. Preshift never reads the generic DATABASE_URL, so it cannot write into another system's database by accident. The hosted API has no public key: people reach it by signing in, and integrations use a key an admin makes under Settings.

Set PRESHIFT_DOCUMENT_KEY (openssl rand -base64 32) before anyone uploads a right to work copy. Copies are encrypted with it and it is never stored in the database; without it, a database deployment refuses uploads and views. Keep a copy of the key outside Vercel: losing it loses every stored copy. Every view of a copy is logged, and admins see the log on the employee record.

Structure

src/engine   Pure TypeScript domain logic, shared by API, browser and assistant. Fully unit tested.
src/ai       The rota assistant: tools over the engine, and the Claude loop that drives them.
server       The Preshift API: routes, the MCP connector, sign-in, people and settings, API keys, tenancy, Postgres store, payroll outbox, TeamPay client and simulator.
src/ui       React web app, a client of the API.
site         Marketing site (static, no build step).
scripts      Local dev runner and the Vercel build.
docs         API and integration guide, strategy and roadmap.

The engine runs in both places: the server is the source of truth, and the browser runs the same code for instant cost and compliance feedback while editing.

Statutory rates

All UK parameters live in src/engine/ukRates.ts and are set for 2026/27. They change every April and must be checked against GOV.UK before each tax year.

See docs/STRATEGY.md for the competitive position, JV model and roadmap.