Software ready before the site gate opens

In March 2023 an engineer reviewing a new subcontractor-compliance export noticed that one report query filtered records by project but not by customer account. With a crafted request, a user at one builder could have retrieved another builder's subcontractor list, including contact names and insurance expiry dates. The feature had been in a limited trial with fourteen customers for nine days. We switched it off within the hour and reviewed every request in the logs. No record from another account had been returned. Our general counsel's assessment was that the event did not require notification under the Notifiable Data Breaches scheme, but we told the fourteen customers what had happened anyway.

The narrow fix took a day. The larger problem was that separation between customers depended on every developer remembering to add the right filter. I proposed pausing new feature work in five of our seven teams for eleven weeks so that the database itself would enforce account separation on every query, with per-customer encryption keys for uploaded documents and an automated test on each release that tries to cross between accounts.

Our chief revenue officer disagreed, and at first so did Megan. A large builder had been promised a prequalification module for July, and the pause made that date impossible. I argued that a second, unnoticed mistake would cost more than any delayed module. Megan agreed after the board's audit and risk committee chair asked to see both plans side by side.

We reviewed 2,140 queries and changed 318. An external penetration test in November 2023 found no path between customer accounts. The work consumed about A$1.2 million of engineering time. The large builder delayed a A$410,000 expansion by a quarter, and one prospect chose a competitor. Every new table must now carry an account policy before it can be merged.

I would have told the committee chair within days rather than at the next scheduled meeting five weeks later. I would also have done this work in 2018, when I first listed it as a risk and twice let it slip behind features.

By mid-2024 our customers had stored about 430 million photographs in site diaries and defect records, roughly 1.1 petabytes. Builders keep these images for years after handover because defect claims and payment disputes can arrive long after a project closes. Storage cost A$1.7 million in the 2024 financial year and was growing by about 35 per cent annually. Total cloud spending had reached 11.6 per cent of revenue, and our investors had started asking whether the product could ever carry its own infrastructure.

My proposal was to move any photograph not opened for twenty-four months to archive storage. Previews would remain instantly available, while the full image would take up to twelve hours to retrieve. Our head of customer success objected strongly, as did two large builders, because adjudication timetables for payment disputes are short and a lawyer may need hundreds of images quickly. I accepted that the change carried a real service cost. Our compromise kept instant access for any project still within its defects period, as flagged by the builder, and we gave every customer ninety days' notice.

Eight months later a builder in a payment dispute needed 3,400 archived photographs within a day. We paid for expedited retrieval and two engineers worked overnight to assemble the set. The builder met its deadline but was rightly unhappy. A smaller civil contractor, paying A$96,000 a year, left us and cited the change.

Storage cost fell to A$0.8 million in the 2026 financial year, against a projection of A$2.6 million had nothing changed. Together with resized compute and a capacity commitment, total cloud spending fell to 8.3 per cent of revenue. Customers can now place a project on hold themselves, which keeps its photographs in fast storage for as long as they choose.

That hold control is my main regret. We built it after the overnight retrieval, when it should have been part of the original change. I designed the policy around our storage bill and only later around the builder's worst week.

At 6.20 am on 27 August 2024, a network fault in our cloud provider's Sydney region, combined with our own single-region design, stopped digital sign-in for forty-seven minutes. About 1,300 sites reverted to paper registers. Some coped well; others delayed their start, and one civil contractor postponed a concrete pour. A state transport agency then asked the builders on its projects for a written resilience plan, and those builders asked us.

We had three options. A warm standby in Singapore would cost about A$290,000 a year and use tooling we already ran. A standby in Melbourne would cost about A$710,000, because it needed new configuration and a more expensive pattern of replicated services. The third option was to improve the paper fallback and accept the occasional outage. Our chief financial officer preferred Singapore. I recommended Melbourne for sign-in, inductions, permits and diaries, while leaving the photograph archive in Sydney with backups in Melbourne.

The deciding fact was contractual. Three state agencies and about forty builders require their data to be stored and processed in Australia. Singapore would have needed contract variations that several customers had already said they would refuse. My first board paper presented the two regions mainly as a price comparison, and directors understandably asked why I wanted the dearer one. The second paper put the residency obligations first. The board approved Melbourne in October 2024. The permits rebuild slipped two quarters because our platform engineers were committed to the standby.

Cutover finished in March 2025 at an annual cost of A$690,000. Our first failover rehearsal took twenty-three minutes against a fifteen-minute objective; the third took nine. Weekday availability between six and eight in the morning was 99.96 per cent across the 2026 financial year. Customers practised the paper fallback with us twice.

I ran the first rehearsal on a Sunday, which hid the effect of morning load and made the result look better than it was. I now insist that rehearsals happen on weekday mornings. I should also have led the first board paper with the obligations rather than the invoice.