Plain English, start here
SkipOps runs the day for a UK rubbish-clearance firm, entirely through Telegram. The boss texts jobs in plain words. The system works out the smartest route for every van. The crew get tap-by-tap job cards on their phones. The boss watches it happen live and ends up with a photo-proof record of every job. No money or pricing anywhere in version 1 — the win is told in saved fuel, time and wages.
The whole thing on one page
Five moving parts. Set the firm up once, then the same loop repeats every working day.
flowchart LR A["① Set the firm up
(once)"] --> B["② & ③ Boss texts
jobs"] B --> C["④ System plans the
smartest day"] C --> D["⑤–⑦ Crew get job cards
+ post photos"] D --> E["⑥ ⑧ ⑨ Boss watches live +
gets the record"] E -. "new job or change
→ re-plan" .-> C classDef here fill:#eef2ff,stroke:#4f46e5,stroke-width:2px,color:#3730a3; class A here;
main (commit 92320e2): Van & crew (who-drives-what) → Waste types → Sites (Google-satellite map per waste, multiple tips, dark all-sites overview) → Ops (3 animated "how it moves" diagrams; skipped if no yard) → Checklist (typed job + yard builder + per-job review-QR — built, Alex-approved, on main). Built + smoke-passed (worker 148 + web 163 tests, check, build all green; contrast AA-checked; walks verified @390px). Owed before go-live: a full live phone walk of all 5 steps + the save-to-Supabase path (apply the new migration, walk to Save, confirm a tenant lands). Nothing is on the public internet yet — deploying is its own later step. Update 5 Jul: a rethought v2 onboarding — 4 steps, sites-first, no crew typing, checklist + required review link — is now on main alongside the original (details in the ①·v2 card below); Alex walked it at phone width and approved it. Choosing which wizard greets a new firm is the next decision.Every stage — what it's for, and where we are
Each one: the plain-English objective (what we're trying to achieve), a quick picture, and an honest done / still-to-do.
main (92320e2) · live phone gate + save-to-DB owedThe objective: before SkipOps can run anyone's day, it has to learn how that firm works. The boss fills in a quick 5-step setup wizard + a review — (1) Van & crew, (2) Waste types, (3) Sites, (4) Ops, (5) Checklist — tap and type, then Next. Each step shows only the one thing it's asking, so it never feels busy. We started at 5/6 steps, collapsed to 3, then split back out to 5 because the honest shape is one clear question per screen: who works here → what waste you handle → where each one ends up → how each one gets there → the job checklist. No AI, no guessing in setup: each step is a plain form our own code checks before you can advance, and the firm is saved at the end. Hours aren't asked — they flex day to day, so the day's window comes from the crew sharing live location to sign in (gaffer's "kick off the day", stage ②).
flowchart LR S1["① Van & crew"] --> S2["② Waste types"] S2 --> S3["③ Sites
(map per waste)"] S3 --> S4["④ Ops
(how it moves)"] S4 --> S5["⑤ Checklist"] S3 --> R["Smart routes +
full-van trips"] S4 --> R
CLAUDE.md. 145 web tests + astro check + build + 5-step gauntlet all green.main): each item now carries a type the crew act on — Tick / Photo / Amount (log what's in the van + how full) / review QR — chosen on a segmented picker. A job checklist (8 defaults in Alex's order; before/after photo + the review ask are locked) plus, when the firm has a yard, a yard checklist (7 defaults). Add / delete / change-type / drag to reorder; locked items can't be retyped or removed. A review-QR item reveals the firm's Google review link (required when present). Per-job review-QR proof: each job gets a unique QR → GET /r/<token> logs the scan and 302-redirects to the review link (endpoint + scan table built and unit-proven; the crew job-card that draws the QR is a later bot slice).PUBLIC_GOOGLE_MAPS_KEY on the VPS + local env.main; the full end-to-end phone walk of steps 1–4 + Review is still owed before go-live.roles/usual_driver + the checklist/review-QR one: review_url, yard_checklist, jobs.review_token, the scan table) and re-run create_tenant on Supabase, then walk the wizard to Save and verify a tenant lands with the typed checklist, yard checklist, review link, per-waste sites + movement, roles, usual drivers, and working_hours: null.wrangler.toml committed; SkipOps isn't on the internet). First deploy = its own job: Cloudflare project + secrets, apply the migrations to the real DB, then the live Pages domain on the Maps key's referrers + swap the deprecated google.maps.Marker pins to AdvancedMarkerElement./v2 next to the original · the swap decision is queuedThe objective: the original wizard makes the boss type in everything — crew, waste types, checklists — before the firm exists. v2 flips that: it asks only what a boss can answer in a minute, and everything else arrives later, in Telegram, where his crew already are. (1) Your firm — the name and how many vans. (2) Your base — one pin on the map. (3) Where does it go? — a card for each place he gets rid of waste: he searches a tip by name (the way he actually knows them), ticks which waste goes there, and the yard is simply the first card — anything ticked on it says whether it's stored then taken on or disposed of right there. (4) Checklist — the same job + yard checklists the original wizard builds (what the crew must tick, photograph or measure on every job), pre-filled so most bosses just glance and carry on — and the firm's Google review link is required here (Alex's call: the "ask for a review" step must always point somewhere real). Nobody types a crew list, ever: when the firm's saved, a share-able link makes whoever opens it the boss's account — so Alex can fill the whole thing in on a sales call and just send the link. If something's blocking the Next button, the screen now says exactly why, right next to the thing to fix (added after Alex's walk caught it staying silent).
flowchart LR A["① Your firm
(name + vans)"] --> B["② Your base
(one pin)"] B --> C["③ Where does it go?
(tip cards + waste ticks)"] C --> CL["④ Checklist +
review link"] CL --> D["Save — the
firm exists"] D --> E["Send the link →
the boss takes over"]
main (merged 5 Jul morning). Alex walked the whole thing at phone width: his first walk failed it on two counts (two buttons touching on the finish screen; a blocked Next with no explanation) — both fixed the same morning, locked in with tests, and the re-walk passed.The objective: for each waste type, capture the disposal site(s) the firm itself uses — the places it actually has access to and an account with. That list is what routing trusts. Why not just auto-find sites for them? Because no data can tell us whether a site will take a crew that turns up unannounced — many require a trade account; some (like Robins) don't. Sending a van somewhere it gets turned away is unacceptable. So the firm names its own (it only ever uses 4–5) — and our whole job is to make that entry effortless: we suggest the real sites near their yard and let them tap to add, instead of making them type everything from scratch.
flowchart LR A["Yard postcode"] --> B["Suggest real sites
near you, by material
(from EA data)"] B --> C["Firm taps to add
· or types its own"] C --> D["The firm's sites,
per material"] D --> E["Routing only ever
uses these"]
disposal_suggestions table — 7,107 real commercial sites (household-only HWRCs excluded), each with what it received by the tonne. Built + loaded local + remote (26 Jun). Live Brighton query surfaces the web-quiet sites the old gate missed (Newtimber/Robins → 24,000t hardcore; OLUS → 36,000t wood).GET /suggestions turns the yard's location into nearest sites per material (keyless OS-grid maths, £0/zero-token) — proven live end-to-end.The objective: every firm gets two Telegram chats — a private one for the boss (the "Gaffer" chat) and a group for the crew (the "Dispatch" group). And a hard wall so one firm can never see another firm's jobs.
flowchart LR A["Firm set up"] --> B["Gaffer chat
(boss only)"] A --> C["Dispatch group
(the crew)"] B --> D["Each firm's data
walled off"] C --> D
The objective: the boss texts a job the way he'd say it out loud — "clear a garage on Dyke Road tomorrow morning, half a load, before-and-after pics." The system turns that into a proper job (where, how big, when, what photos) and reads it back so any misread is caught on the spot.
flowchart LR A["Boss texts it
in plain words"] --> B["System understands:
where, size, when"] B --> C["Job created"] C --> D["Reads it back
to confirm"]
The objective: given the day's jobs, work out the most efficient round for every van — fewest miles, fullest loads — including nipping back to the yard to empty when a van fills up, then carrying on. This saving (fuel, time, wages) is the whole pitch.
flowchart LR A["The day's jobs"] --> C["The planner"] B["The vans + capacity"] --> C C --> D["Most-efficient
route per van"] D -. "van full →" .-> E["empty at the yard,
then carry on"] E -.-> D
The objective: once the day's planned, each van gets one clear, friendly message — their stops in order, what to expect, and a tap-to-navigate link for each stop that opens their own phone's maps. Nothing new to learn.
flowchart LR A["The day's plan"] --> B["Friendly message
per van"] B --> C["Stops in order"] B --> D["Tap-to-navigate
per stop"]
The objective: each driver taps "share live location" in Telegram once at the start of the day. That's it — the system now knows where every van is, with no app and no tracking box to fit.
flowchart LR A["Driver taps
'share location'"] --> B["System knows
where each van is"] B --> C["Feeds the
boss's live map"]
The objective: the crew snap a before and an after photo and tick the job checklist. The system files them against the job, so there's a permanent, proof-backed record of every clearance — plus a note of exactly who was on that team that day.
flowchart LR A["Crew: before +
after photos"] --> C["Filed against
the job"] B["Checklist ticked"] --> C C --> D["Permanent
proof record"]
GET /r/<token> logs a scan to the scan table and 302-redirects to the firm's Google review link (unit-proven; gives the boss a "review asked · HH:MM" signal later).The objective: jobs change all day — a new one comes in, one's cancelled, a van finishes early. When that happens the system quietly re-plans the rest of the day and re-sends the routes, without anyone asking.
flowchart LR A["New / cancelled job,
or van free early"] --> B["Re-plan the
rest of the day"] B --> C["Re-send the
updated routes"]
The objective: one screen for the boss — a live map of his vans and jobs, a list he can filter, and a tap into any job to see its photos, crew, checklist and timings. His whole operation at a glance.
flowchart LR A["Live van pins"] --> C["Boss dashboard"] B["All the jobs"] --> C C --> D["Tap a job → photos,
crew, checklist, times"]
Staying on track
Calibration wizard is done. Rewrite the docs for the new sign-in strategy, then build the daily loop in the order the day actually runs.
main (5 Jul): the original 4-step at /, the approved v2 4-step at /v2. Pick which one greets a new firm — and if it's v2, plan the original's retirement plus v2's two follow-ons (auto-find the firm's review link; build the "later, in Telegram" arrival for crew + checklists).main (92320e2): Van & crew · Waste types · Sites (Google-satellite map per waste, multiple tips, dark overview) · Ops (3 animated "how it moves" diagrams; skipped with no yard) · Checklist (typed job + yard builder + per-job review-QR — built, played-with + signed off in-pane). Left: Alex walks steps 1–4 + Review end-to-end on his phone, then apply the migrations (roles/usual_driver + review_url/yard_checklist/scan/jobs.review_token) and walk to Save to confirm a tenant lands. Going live (first Cloudflare deploy) is a separate later job.Mission: 20 paying firms at £75/mo by 5 Nov 2026. Roughly the first stretch is finishing the build; the rest is selling it.