Rory

Rory 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 Rory 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 Rory 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.

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 central design decision was about what Rory 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 Rory around a principle the trade respects: humans make the decisions, tools do the preparation. Rory 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. Rory 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 Rory 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.

If Rory 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 Rory 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 Rory 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.

The approval model needed its own surface, not a buried confirmation dialog. When Rory 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. Rory 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 Rory 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 Rory is working on, and what it has learned, trusts it faster and corrects it sooner.

Two decisions came straight out of the field.

Mobile-first, and usable with one hand. The people Rory is for are on site, not at a desk. The phone is the primary surface, deliberately minimal, fast to scan, with the primary actions reachable with a thumb, and the web app is the desk. Same product, same data, whichever one a builder opens.

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.” Rory 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 Rory 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.

The first mobile app was a Capacitor 7 shell wrapped around the web app. It was the pragmatic call, and I still think it was the right first move: one build, both stores, all the product work already done. It shipped to TestFlight, and for a few weeks I kept patching it toward feeling native.

The problem was that none of the patching was product work. It was the seam between a web view and an operating system, and every week produced another one. The tab bar showed on a screen that should not have had it. A text field went unreadable while you typed. A permission crashed the app on launch. The launch logo sat ten per cent of the screen below centre, because Capacitor’s splash plugin and the shell disagreed about where the safe area started, and it took a day of reading someone else’s source to move a logo to the middle of a screen.

Meanwhile the things a builder actually feels in the first five minutes, that a scroll has weight, that a tap answers immediately, that a sheet moves the way every other sheet on their phone moves, were never going to arrive by patching. It read like a website wearing an app icon.

For a product whose entire proposition is trust, that gap mattered more than it would for most software. A builder deciding whether to let Rory near their inbox reads the interface before they read the feature list. Nearly native is a tell, and it is the wrong one.

So I rebuilt it properly, and took a wrong turn on the way.

The wrong turn was Kotlin Multiplatform: SwiftUI on iOS, Compose on Android, a shared Kotlin core. It worked, and the design held up. I took the patterns from apps builders already use, Apple Mail’s inbox, Apple Books’ onboarding, Apple Music’s mini player, which became the bar that sits above the tabs while Rory is drafting. But it cost two native codebases, which is the right answer for a team and the wrong answer for one person who also has a backend, a web app, and pilot customers waiting. I landed it as a checkpoint so the design work was not lost, and started again on React Native and Expo.

That rewrite replaced both the Capacitor shell and the Kotlin app in one pass: one codebase, two platforms. From Capacitor I kept only what the app stores already knew about, the bundle identifier, the deep-link scheme, the permission strings. Everything above that is native now: system tab bars instead of a floating web pill, SF Symbols, iOS sheets that behave like iOS sheets, haptics on anything that commits, and the session in the device keychain rather than browser storage. Accessibility went in at the same time, since the alternative is retrofitting it: 44pt minimum targets, a screen-reader label on every control with a test that fails the build if one is missing, AA contrast on both the light and dark surfaces, and motion that respects the reduced-motion setting.

Then the unglamorous part that decides whether any of it is real: getting builds into testers’ hands. The app builds and archives on Xcode Cloud, and a scheduled job releases the newest passing build to TestFlight on its own, which I wrote after Apple stopped honouring the setting that used to do it and builds sat processed but undistributed with nothing failing to tell me. Releases now happen without me in the loop, which is the only state in which a pilot teaches you anything.

The web app did not go away. It stays as the desktop surface and the product’s source of truth. The phone is where the work gets caught, the desk is where it gets set up.

Rory 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 runs where the work does, as a native iOS and Android app for the site and a web app for the desk, off one React Native codebase and one backend. 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. Rory 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. Rory 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. Rory 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.

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 Rory 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 Rory 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 Rory 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. Rory 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.

Rory is in pilot. The core product is functional, the iOS app is past its thirtieth TestFlight build and distributing to testers automatically, 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 Rory 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.

I started Rory thinking it was a way to give a builder back two hours of admin a night. It does that. But the more discovery conversations I sat in, the clearer it got that the admin was the symptom. What a builder is actually short of is a read on their own jobs: which one is stuck, what is holding it, and which of those blockages is quietly costing money. The admin is only the work you do to clear it. Once I saw the problem that way, Rory stopped being a tool that does chores and became a tool for communicating, with the agent, and through the agent, with everyone a job depends on.

That reframing is why each surface is shaped the way it is. Today answers what matters to this person, on these jobs, this morning, and deliberately nothing else. The Inbox is not mail, it is the set of open loops causing problems across every job. The Rory tab exists so a builder can start work that would otherwise need a desk or an administrator sitting beside them. And Projects is pointedly not the dashboard that project management software would put there: no schedule grid, no burn-up, just what needs doing, what has gone wrong, and a way to tell the client about it. Rory then does the admin that clears the blockage, and waits.

The design constraint underneath all of it turned out to be 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 rebuild taught me a version of the same lesson about knowing when to stop defending a decision. Shipping the Capacitor wrapper was right, and keeping it would have been wrong, because the effort had quietly stopped going into the product and started going into the gap between a web view and a phone. The signal to rewrite was not a feature I could not build. It was noticing that three weeks of commits were all platform plumbing, on a product whose credibility rests on how it feels in the first five minutes.

That credibility is the last thing I would take out of this. 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 fact that nothing gets migrated, and the plain sentence at the top of the day telling you what is actually wrong. Building it end to end myself meant I could hold that from the first discovery interview through to how the app behaves in a builder’s hand.