Site Ahead

• 

  Project Architecture

• 

  Project Structure

Inspiration

Meet Bob. He is an operations manager at a civil contracting company in Victoria, twenty years in the trade, and a father of two who would like to be home for dinner. A client texts him an address and a few lines about a job. Before Bob can price that job or send a crew, he needs to know what is actually waiting at the site: is there anything underground, does it need a permit, will traffic management be required, can plant even get in?

Today the only reliable way to answer those questions is to drive there. So he does — across town, in traffic — and often finds that the job needs a permit he has not applied for, or that a services clearance is still outstanding, or that access is nothing like what the client described. The quote changes, the schedule slips, and he explains the delay to both the client and his own crew.

The thing that started this project was a simple observation: almost everything Bob drives out to learn is already knowable before he leaves. It is just scattered across maps, council pages, BYDA, old emails, and whatever the most experienced person on staff happens to remember. Nothing holds it in one place, and nothing tracks which checks are genuinely resolved versus quietly assumed to be fine.

We also checked whether someone had already solved it. The obvious "site intelligence" players — TraceAir, OpenSpace, Sensera's SiteCloud — are real, funded products, but they all point at during-construction visual monitoring: drone and 360-camera progress capture for large builders. We could not find anything aimed at pre-visit due diligence for a contractor deciding what they are walking into before they have even quoted. Everyone is watching the construction. Nobody is watching the drive there.

The second observation is the one that shaped the whole build: there is no single fixed checklist. An excavation job needs traffic, underground services and dust. An electrical job needs prescribed-work classification and inspection timing. A renovation needs permit thresholds and asbestos risk. A generic checklist app does not solve this, because the content has to change completely per job while the process stays the same.

What it does

SiteAhead is a pre-visit site recon agent for trade contractors. It is contractor-only — the client never logs in, and only ever receives a message the contractor has read and approved.

In: an address, a job type, and whatever the client actually said, pasted from the chat or spoken aloud and transcribed.

Out: a live, job-specific checklist that resolves itself, plus a synthesised pre-visit report.

The core mechanism is that every checklist item is sorted into exactly one of three lanes the moment a job is created, so that every row has an owner and a next action instead of a flat "needs further investigation" list:

Automated checks — resolved instantly, either from a public data source or from a simple internal rule such as a job-value threshold or a work classification. Nobody has to do anything. Pending → Done, with the underlying evidence viewable on the item.

Third-party requests — the answer or approval lives with an external body: an asset owner, a council, a regulator, an inspector. SiteAhead prepares the form or enquiry, the contractor reviews and sends it, and SiteAhead tracks it until a reply closes it out. Not started → Drafting → Ready to send → Awaiting reply → Done, with an overdue flag once a known response window passes — BYDA's two business days, a road-reserve permit's twenty, an electrical inspection's eight.

On-site checks — nothing external can answer this. It needs a person's judgement, either at the site or on paperwork only a licensed trade can complete. SiteAhead does not pretend otherwise; it just tracks that the check still needs doing. Not started → Done, ticked by hand with an optional note.

Two rules make the engine trustworthy rather than merely clever:

• Nothing disappears. If an automated check's source cannot answer, the item does not vanish — it falls through to an on-site check, carrying the reason with it, so a person still owns it.
• SiteAhead never sends anything on its own. Drafting is automatic. Sending is always a human action. That is a product rule, not a missing feature.

The checklist is tailored by what the client actually wrote. Job type alone is not the whole picture — two carpentry clients can describe completely different work. The client's own words feed a bounded classification step that picks a job subtype from a fixed list and flags which known trigger phrases are present. One client writes "extending the back deck, house is from the 70s, right up near the back fence" and the base carpentry list gains a pre-1990 asbestos assumption and a boundary consent. Another writes "just replacing some rotted skirting boards inside" and gets the bare base list. Same trade, genuinely different checklists, driven by what the client said.

Four trades are covered — excavation and trenching, electrical, plumbing, and carpentry and renovation. The rows change completely between them. The engine never does.

Finally, SiteAhead writes the pre-visit report: what is confirmed, what is still waiting on someone else, what has to be done on site, what the risks are, and a drafted message for the client. It will not report a prepared request as an answered one.

How we built it

(The product walkthrough and the system architecture are covered in our demo video — this section is about how we approached the build.)

We costed the problem before we wrote the product. Rather than assume the pain was real, we built a cost model of Bob's current process from published Australian data, and only then designed against it. The model is per-job and it is deliberately conservative:

Per job	Before	With SiteAhead
Reconnaissance trips (labour + vehicle)	$142.73	$71.37
Regulatory desk work	$38.23	$15.29
Return visits (labour + vehicle)	$57.09	$22.84
Platform subscription	—	$7.49
Total per job	$238.05	$116.98

That is $59,513 a year down to $29,246 for a small crew doing 250 jobs — a 50.9% reduction, $121 saved per job, and the subscription paying for itself 16.2 times over.

Every variable is sourced: ABS construction wages, the ATO cents-per-kilometre rate, BITRE urban travel speeds, an ACCI compliance survey cited by the Small Business Ombudsman, and the published field-service first-time-fix benchmark. Where we could not support a variable with data, we left it out of the model rather than estimating it. Where a variable was unavoidable but unsourceable, we named it as a business input rather than dressing it up as a finding.

We treated the checklist as a data problem, not a UI problem. The trade library — base rows, trigger rules, and the phrases that fire them — is data. Adding a trade is a set of rows, not new code. The three lanes are modelled as a discriminated union so each lane only ever carries the fields it can actually have: evidence and a source for automated checks, a draft and a response window for requests, a completion note for on-site checks. Item status is kept separate from execution state, so "the agent finished running" never gets confused with "the item is done".

We bounded the AI on purpose. The classification step selects from a checklist library we defined; it cannot invent a check. Everything downstream of it — which rows appear, which lane they land in — is deterministic.

Stack: React and Vite on the front end, Convex for the backend and data, Google sign-in through Convex Auth, OpenAI for the bounded extraction and report synthesis, and ElevenLabs Scribe for voice intake. We worked spec-first using OpenSpec, so the repository carries a full, reviewable history of what was proposed, designed and implemented.

On what is live and what is seeded: public-data evidence such as traffic conditions and air-quality readings is seeded for this build and labelled Demo data in place, wherever it appears. We would rather a judge know exactly which numbers are live than discover it later. The engine, the status flows, the request tracking and the report are all real.

Challenges we ran into

Designing for "there is no single fixed checklist." Our first instinct was a checklist feature. That is wrong: the value is in the engine being job-agnostic while the content changes completely per trade. Getting to "same table, different rows" took more design argument than code.

Building an honest after-cost. It would have been easy — and much more flattering — to model the saving as near-total. We could not defend that, so we built the after case to fight us: half the reconnaissance trips still happen, 40% of the desk hours stay because a person still reviews and sends every request, the first-time-fix rate is capped at 95% so the model can never imply every job closes first time, and we charge ourselves full market price for the software. The after cost is $116.98, not zero, and every one of those four constraints is an editable input so a sceptical reader can tighten any of them and watch the saving fall.

Sourcing discipline. The temptation with a cost model is to fill every cell. We deleted more variables than we kept — client-side delay costs, rework, lost quotes, permit fees — because we could not tie them to a credible published figure for Australian trade work. Where we used a supplier's own case study, we halved it before using it, and left the discount as an input.

Deciding what happens when automation fails. An automated check whose data source cannot answer is the most dangerous item on a checklist, because it can silently disappear. The fall-through rule — convert it to an on-site check and carry the reason — came out of that problem and ended up being one of the things we are most pleased with.

Scope in a 48-hour window. We cut hard. Live API integrations, multi-user workspaces, equipment and materials tracking, and a location profiling screen were all built or scoped and then deliberately removed, because none of them were the core mechanism. What survived is one contractor, one job, one checklist, one report.

Accomplishments that we're proud of

The engine is genuinely job-agnostic. Four trades produce four unrecognisably different checklists from the same table and the same status logic. You can watch an excavation job and an electrical job at the same address generate completely different work, and nothing about the interface changes.

The tailoring actually works from the client's own words. Typing a real client message into intake visibly adds the rows that message warrants, and names the trigger rules that did not fire — so you can see what the system considered and rejected, not just what it decided.

We can show our working on the money. Most hackathon value claims are a number on a slide. Ours is a workbook where every variable carries its source, its evidence tier, and the argument for using it — including the ones we marked as assumptions rather than facts.

We said no in the right places. Never sending on the contractor's behalf, labelling seeded data as seeded, refusing to claim a zero after-cost, and moving failed checks to a person instead of hiding them. Each of those makes the product look less impressive on a slide and more trustworthy in use.

What we learned

Quantify before you build. Costing Bob's current process first changed what we built. It told us the reconnaissance trip and the return visit were where the money was, which is why the product targets those and not, say, quoting.

Narrow ruthlessly. Every feature we cut made the demo clearer. The version we are submitting does less than the version we designed on day one, and it is a much better product for it.

Bounded classification beats open-ended generation. Letting a model select from a library we defined gave us behaviour we could predict, explain and test. Letting it invent checks would have given us a demo that fails in front of judges and a product no contractor could rely on.

Honesty is persuasive. The two moments in our pitch that land hardest are the line that goes up — the subscription — and the sentence "not zero, and we will not claim it is." Volunteering the weaknesses before anyone asks buys more credibility than a bigger number would have.

The users' world should set the design language. Square corners, hi-vis amber on charcoal, dense tables built for someone running many jobs at once. The interface looks like the industry it serves rather than like every other SaaS dashboard.

What's next for Site Ahead

Live data sources. Swap the seeded traffic, air-quality and property reads for the real APIs behind them. The lane and the evidence panel already exist; this is a matter of wiring the sources in and keeping the fall-through rule for when they fail.

More trades. The library is data, not code. Each new trade — roofing, concreting, HVAC, demolition — is a set of rows and trigger rules, not a new product. The engine is already proven across four.

Close the reply loop. Today the contractor records a reply by hand. Watching the inbox for a matching response would let a third-party request close itself, which is the last manual step in the tracking flow.

From checklist to quote. Once the resolved checks carry real evidence — permit likely required, inspection booked, asbestos assumed — that is most of the input to a defensible quote. Turning a completed pre-visit report into a priced job is the natural next step.

---

Team **Subject to Change* · Track 3 — Solve a Problem*

Built With

• convex
• react
• typescript
• vercel