Product · prototype on sample data

Six screens. One ticket.

The prototype runs on a fictional fleet, “Demo Pumping & Crane Co.”: 6 concrete pumps, 4 boom trucks and 3 cranes, 12 operators and 5 sample customers. Every screen works, keeps state in your browser, and carries a demo-data banner.

Open the prototype

aDispatch board

Machines on rows, the next seven days on columns. Drag an operator onto a job (or tap, then tap, on a phone). While an operator is selected, every job lights up green, amber or red depending on whether that person holds the right NCCCO certification for the machine and a current DOT medical card.

Expired NCCCO card or medical card: hard block and a red badge, as the spec asks.
A switch in Settings shows the alternative the plan recommends: a soft block with a logged owner override.
No certification for the machine type at all is always refused.
Double-bookings and expiring-within-30-days are flagged amber.

Open the dispatch board →

bPaste order

Paste an email, a text or a call note. The job card fills itself: customer, contact, site address, pour volume or pick weight, date and start time. Fields under 70% confidence are highlighted for the dispatcher, each with the reason (“range given, used the top”, “no time; default 07:00”). A suggested unit comes with its sizing rule.

Honest label: in the prototype this is a rule-based parser running in your browser, not a language model. In the plan, AI intake is a commodity convenience scheduled after customer #10, never a differentiator, and every drafted card needs a human to confirm it. Lift-unit suggestions use a rough rule of thumb and are not a lift plan.

Try paste order →

cOperator ticket

Phone-width. Four big buttons: clock in at the yard, arrive on site, leave site, clock out at the yard. The ticket works out travel each way, time on site and portal-to-portal. Yards pumped, washout, photos from the camera, the customer’s name and a finger signature, then submit.

The planned production app is native and offline-first with a server-acknowledged outbox, because a ticket stranded on a phone recreates the lost-ticket problem. This browser version exists only to demo the flow.

Open the operator ticket →

dInstant pricing and invoice

The signed ticket prices itself against an editable rate sheet: hourly by machine class, a 4-hour minimum, overtime after 8 paid hours at ×1.5, travel at its own rate, a washout fee and an optional per-yard charge. Every line shows the rule that produced it. Change a rate and every ticket reprices.

“Push to QuickBooks” sends an invoice payload to a mock endpoint in your browser. It refuses until the customer has approved the ticket, and it is idempotent: pushing the same ticket twice returns the existing invoice instead of a duplicate.

Open pricing →

On-site time 7.50 h × $195$1,462.50

Travel 1.75 h × $125$218.75

Overtime premium 1.25 h × $97.50$121.88

Pumped volume 48 yd³ × $3.50$168.00

Washout$150.00

Subtotal before tax$2,121.13

Sample ticket, sample rates.

eLeakage report

The demo’s money screen. It reprices 90 days of seeded historical tickets against the rate sheet and compares them with what the paper process billed: dollars of unbilled overtime, missed minimums and travel, plus washouts and lost tickets. Minimums a customer has a standing waiver for are shown separately and not counted.

Two things this screen cannot tell you. First, the leak rates in the seeded history were chosen by us to make the demo readable; they are not evidence. Second, a real paper shop has no 90 days of machine-readable tickets to rerun. The plan’s real sales tool is a 2-week on-site photo audit of dispatched versus invoiced jobs, counting only losses the owner agrees were real misses.

Run the leakage report →

fCustomer portal

The contractor’s view: ticket history with hours and amounts, a PDF of any ticket (generated in the browser and stamped as sample data), and one-click reorder that copies the site, work and machine class into a request on the dispatcher’s queue.

Open the customer portal →

Ticket	Hours	Amount
T-5001	11.25	$3,233	PDF Reorder
T-7342	5.00	$1,190	PDF Reorder

Sample rows.

Where the prototype and the plan disagree

We built what was asked, and we say where we’d do it differently

Hard block vs. soft block

The spec asks for a hard block on expired credentials. The plan recommends a soft block with a logged owner override: a mistyped expiry date should never stop a 5am pour, and the vendor should not become part of the employer’s OSHA 1926.1427 operator evaluation E OSHA. The prototype does both behind a switch.

Pumps and cranes first vs. hydrovac first

The demo fleet is pumps, boom trucks and cranes. The plan puts pumping third, because CreteSuite claims more than 20% of US pumping revenue already runs through it E cretesuite.com (vendor claim), and warns against leading with cranes. The lead niche will be whichever the market count shows is least on software.

Six screens vs. a four-part v1

The plan’s first build is only the e-ticket, the rate engine, invoice sync and the audit log. The drag-assign board, AI intake, credential tracking and the customer portal come after customer #10. The prototype shows the whole picture for demos; it is not the build order.

90-day rerun vs. 2-week photo audit

A rerun of 90 days of tickets makes a strong demo, but paper shops don’t have that data. The real audit photographs two weeks of tickets on site, claims only what the owner agrees was missed, and costs 10–25 founder-hours each.