This is a working product, not a mockup.
You were just looking at a high school basketball program. Every number on it comes out of a real database, the assistant is a real model reading real data, and the operator console behind it is the same software the coach would use on a Tuesday. Nothing on it is a screenshot.
It is a showcase, so the team is fictional — no real teenager's information is on this deployment. Everything else about it is the real thing.
Every one of these you can check yourself.
A real database, not a JSON file
Postgres. Every lead, RSVP, note, announcement and box-score line is a row that persists, syncs across devices, and is still there tomorrow.
Submit the form on the home page — it lands in the operator console.
An assistant grounded in this program's own data
Ask The Right Hand a question and it answers off this roster, this 26-game schedule and the confirmed box scores — not off the open internet. It streams as it thinks.
Every answer lists the sources it actually read.
A vision model that reads film into rows
Point it at game footage and it reads jerseys and makes off the tape into a draft box score. A human confirms every line before it becomes a number anyone sees.
Frames it can't read are reported unreadable, never guessed.
Two surfaces, one system
A public site anyone can use and a locked operator console behind it. Same data, different doors. What the operator writes shows up publicly in seconds.
The console is at /desk. There's a read-only pass below.
It does work while nobody is watching
Two scheduled jobs run on their own. Overnight it drafts tomorrow's practice plan off the last game and turns new signups into a reply the coach can approve; Monday morning it writes the week's digest. Nobody clicks anything.
Every run is logged in the console's Automations room, including the ones that found nothing to do.
It tells the truth when something is off
No API key on a deployment and the assistant says so plainly instead of inventing an answer. A build that fakes a reply when it's broken is worse than one that stops.
That behaviour is enforced in the code, not left to good intentions.
What each piece is, in your business.
The sport is the costume. Underneath it, this is the same shape as a shop, a clinic, a dealership or a studio: records you work off, an intake that feeds them, comms that go out, and one screen that runs it.
The records your work actually revolves around, in one place, with the history attached.
Not a chatbot guessing from the internet — one that answers off your records, your schedule, your numbers.
Invoices, delivery notes, intake forms, voicemails, site photos. Read into data a person confirms before it counts.
One message, written once, out to everyone who should get it — with a record of who got what.
Quote requests, bookings, waitlists, callbacks. Off a public page, into your database, onto your screen.
Tomorrow's plan drafted off yesterday's result; every new enquiry already read, sorted and answered in draft. You approve, you don't write from scratch.
Where things stand, what moved, and the two or three things actually worth your attention.
One console instead of five tabs, a spreadsheet, and a group chat.
The part customers see — fed by the same data you run the business on, so it's never out of date.
The parts that don't work, and why they say so.
SMS and email broadcast
The compose screen works and the message is queued, but nothing sends — carrier registration (10DLC) has to be approved before a single text can go out, and it hasn't been for this demo. The history reads NOT DELIVERED, because it wasn't.
Payments
The booster fund and team store are previews. There is no payment processor in this build at all, so the donate button doesn't move the total and no order is placed. Wiring it is a known, scoped piece of work — it just isn't done here.
Roster auto-sync
The roster is seeded, not synced. Pulling live from an external stats provider is built to be plugged in and isn't plugged in on this deployment.
How fast the automation reacts
The scheduled jobs are real, but this demo runs on a hosting plan that allows two of them and will not run either more than once a day. So a signup that arrives at nine in the morning is drafted that night, not within the minute. That is a plan limit, not a build limit — the same code runs every fifteen minutes on a paid tier, and it is a config line, not a rewrite. We would rather show you the ceiling than let you find it.
Event triggers
Everything scheduled works. Nothing event-driven does: there is no webhook, no queue and no inbound text or email handler in this build, so nothing reacts the instant it happens. Where that matters for your operation, it's a known piece of work.
Why we show you the broken half
Because you can check. Any demo can claim everything works; the bill for that claim arrives in week two of a real project, and the buyer remembers who made it. Every item above is a scoped piece of work we can price — and the fact that this build labels its own gaps is the most useful thing on this page.
Look inside the console
The operator side is where the actual work happens. A read-only pass lets you open every room, read every screen and run the assistant — without writing anything to the database and without spending API credit. The AI rooms show real saved output, clearly labelled as saved, rather than pretending to generate.
Reads everything. Writes nothing. Spends nothing.
Coach B is one build with three audiences. These sign you in as the other two, on the same fictional team — so you can see exactly what a player and a family get.
What this would take for you
It starts with an audit: we go inside how you actually work, and map what's worth building, what it costs and what it returns — before anyone writes code. What you just clicked through is the kind of thing that comes out the other end.