Where it started
Sam started with a specific person: the builder who runs fifteen to forty jobs at once and quietly does two extra hours of admin every night to keep them all straight. Not because they are disorganised, but because the tools they use do not talk to each other. The email lives in one place, the project data in AroFlo, the numbers in Xero, the plans in a Drive folder, and the only thing joining them together is the operator’s memory.
I took Sam into Venture Catalyst as a founder venture through my studio, Mania Design. I had already built two AI products before it, Occhio Inspector and Occhio Scan, and Sam followed the same instinct: find a real operational problem, design a system around it, and build it. This one just happened to sit in an industry with hundreds of thousands of small operators and almost no software built for how they actually work.
The problem space
I ran discovery interviews with active construction operators in South Australia, and the same pattern came back every time. One minor works coordinator managing more than forty simultaneous jobs described his administrator as the de facto source of truth for the whole business, a single point of failure that could not scale. Another custom builder put a number on it: the equivalent of one to two full working days a week lost to administrative coordination alone.
The cost of that fragmentation is not abstract. Variations, the scope changes that generate billable revenue, get raised verbally on site and never recorded, so the money is earned but never invoiced. Follow-up requests to subcontractors stall because no reminder system exists. Approvals sit idle, buried in email. Adding more staff does not fix it, because splitting the admin across more people reduces the contextual awareness each person holds about any single job, which is exactly the awareness needed to catch a problem before it gets expensive.
The insight I kept coming back to: this is not a lack-of-software problem. Builders already have plenty of software. It is a lack-of-connective-tissue problem. Nobody was reading across the systems and telling the operator what mattered today.
The bet
The central design decision was about what Sam is allowed to do on its own, and the answer is nothing.
The construction industry has a well-earned distrust of automated systems touching anything financial or contractual. So I built Sam around a principle the trade respects: humans make the decisions, tools do the preparation. Sam reads, triages, and drafts. It writes the follow-up, builds the quote off real supplier pricing, prepares the variation record. But every action that leaves the building, every email sent, every quote pushed to AroFlo, every spreadsheet row written, routes through an explicit approval step first. Sam prepares the work. The builder authorises it.
That constraint became the spine of the whole product. It is the reason a skeptical operator will let Sam near their inbox at all, and it turned out to be a better design brief than “automate the admin” ever would have been. The job was never to replace the builder’s judgement. It was to do everything up to the point where judgement is actually required.
Designing the daily feed
If Sam does not act on its own, then the core interface is not a control panel, it is a briefing. I designed the home screen around one question a good administrator answers every morning: what needs you today.
The feed pulls from every connected system and sorts by what is actually actionable, grouped into plain categories a builder can scan in seconds: approvals waiting, messages needing a reply, tasks due or overdue. Each item carries the job it belongs to and a single next action, so the operator is never more than one tap from dealing with it. The design goal was that a builder could open Sam in the ute before walking on site, take in the state of every job, and clear the things that only they can clear, without processing a single raw email.
Everything is project-centred underneath. A builder does not think in inboxes, they think in jobs, so Sam canonicalises the same person, supplier, and site across Gmail, Outlook, AroFlo, and Xero, and hangs every message, quote, and document off the project it relates to.
Approval-gated by design
The approval model needed its own surface, not a buried confirmation dialog. When Sam prepares an action it becomes a first-class object: who requested it, which job it belongs to, when it expires, and a preview of exactly what will be sent or written. The builder reviews the real artefact, the drafted email body, the quote line items, the spreadsheet rows, and approves or rejects it. Nothing executes until they do, and every decision, approved or rejected, is logged with a timestamp.
That audit trail is not a compliance afterthought, it is part of the value. When an administrator leaves or is off sick, the accumulated context about every active job usually walks out the door with them. Sam holds that context and makes the record of what was done, and approved, available at any time.
I kept the agent’s own work visible too. An activity view shows what Sam is doing in the background, drafting, retrieving, reconciling, so the system never feels like a black box. Transparency was the whole point: a builder who can see what Sam is working on, and what it has learned, trusts it faster and corrects it sooner.
Meeting builders where they already work
Two decisions came straight out of the field.
Mobile-first, and usable with one hand. The people Sam is for are on site, not at a desk. The interface is a progressive web app optimised for a phone, deliberately minimal, fast to scan, with the primary actions reachable with a thumb. No install, no app store, no migration.
Voice, because typing on site is a non-starter. A builder can hold to talk and ask “where are we at with the office fit-out?” or “draft a follow-up to the plumber about the delay.” Sam transcribes it, and critically, shows the transcript for review before it becomes anything. Same principle as everywhere else in the product: prepare first, let the human confirm.
And because Sam sits above the existing stack rather than replacing it, adopting it costs a builder nothing they are precious about. It connects to the email and tools they already run. There is no new system of record to migrate to, which is the single biggest reason construction software goes unused.
What I built
Sam is a real, working product, not a prototype, and I designed and built the whole thing end to end. What matters from the outside is what it does, not how it does it.
It plugs into the tools a builder already runs, email, AroFlo, Xero, calendars, cloud storage, and live supplier pricing, and works across all of them at once. There is nothing to migrate and nothing new to learn. Sam reads the whole picture of a job the way a sharp administrator would, then quietly gets the next piece of work ready to go.
It gets more useful the longer it is used. Sam picks up how a particular builder works, who is who on each job, which suppliers matter, how they like things worded, and puts that to work without being asked twice.
And it never crosses the line that makes the whole thing trustworthy. Sam prepares, the builder decides. Approval is not a setting that can be switched off, it is the way the product works, so nothing ever leaves the building without a person signing off. That single decision, more than any feature, is what earns a builder’s confidence.
Shipping Phase 1, scoping Phase 2
Phase 1 established the core: email ingestion, the unified priority feed, follow-up tracking, variation detection, and the connectors to the systems builders already run. I wrote it, then audited it against the plan, and used that audit to scope Phase 2 as eight features in priority order, each one either extending infrastructure that already existed or putting a UI on top of a working backend.
The sequencing was deliberate. The fastest wins were UI-only builds on top of live backends: a rules page so builders can see and correct what Sam has learned, a weekly digest, a quote follow-up dashboard that replaces the spreadsheet builders most commonly maintain by hand. The heavier features, a contacts page that turns Sam into a lightweight CRM without any manual data entry, document completeness checking, schedule awareness that extracts dates out of email, and full variation reconciliation from detection through to billing, build on the same data Sam is already collecting. Every item was scoped against real implementation effort, so the roadmap stayed honest rather than aspirational.
That last one, variation reconciliation, is the clearest line from the product back to the problem. Sam already detects variations in email. Closing the loop, cross-checking them against AroFlo and Xero and flagging the ones that were approved but never billed, turns a nice feature into revenue protection. A single recovered variation, a realistic and common scenario from the discovery research, pays for months of the product.
Where it is now
Sam is in pilot. The core product is functional, and it is going into paid trials with early builders in South Australia, the same operators whose problem the discovery research described. This phase is about testing the thing against real inboxes and real jobs: does the feed surface the right items, does the approval flow feel safe rather than slow, does Sam actually save the hour or two a night it was built to give back.
It is early, and honestly reported as early. The build is a working pilot, not a polished demo. But it does the whole loop end to end, read across the systems, surface what needs a decision, prepare the work, wait for approval, and that loop is the whole idea.
Reflection
The most useful thing I learned building Sam is that the constraint was the product. “Automate construction admin” is a worse brief than “prepare everything, decide nothing,” because the second one tells you exactly where the software stops. Every hard call, what to surface, what to draft, what to log, what to never touch, got easier once the line between preparation and authority was fixed.
The other lesson was about trust as a design material. In an industry that has watched software over-promise for a decade, the features that earn adoption are not the clever ones. They are the visible activity feed, the approval that cannot be skipped, the credentials scoped to a single task, the fact that nothing gets migrated. Building it end to end myself meant I could hold that principle from the discovery interview all the way through to how the product behaves in a builder’s hand, so the thing a builder feels in the first five minutes, that Sam does the work but never takes the decision, is true at every level underneath.