Helping a Brisbane mortgage brokerage build and ship with AI, safely
Both owners now build with AI, and the principal publishes website changes himself. This is how that was set up, and what I’d carry to another team.
At a glance
- Problem. A team new to AI. The principal worried a new page would “break the site”.
- What I did. Built guardrails for that worry, hardened a co-owner’s AI-built intake app for production, and added an API so the team’s AI tools can edit the CMS.
- Outcome. Both owners build with AI. The principal ships content changes himself, inside checks I set up.
- Finding. Agents on bounded jobs, with a person signing off, worked. Hands-off autonomous delivery was not ready.
- Scope. The figures count work shipped. They say nothing about leads, rankings or revenue.
Guardrails first, aimed at the principal’s worry about breaking the site
The principal’s worry about the new website was that a new page would break it. So I built the safety net for that worry.
- Drafts and protected previews. Draft pages are not public: a draft address returns a 404 to visitors. Previews sit behind deployment protection.
- A publish rule you can see. In September the principal pressed what he thought was “deploy”, and the live page didn’t change and nothing errored. The editor now shows the five conditions a change has to meet to go live.
- Staged releases with checks. Since 14 July 2026, work reaches production through staging in lettered releases (46 by 24 September). Each pull request needs passing CI, an independent review and a layout sweep.
- A block guide. The block picker was redesigned so editors, and their AI, can see what each content block does.
He now ships content changes himself. The same habit came from a lead-form failure that went unnoticed for about a day. After it, a daily test enquiry ran through each main lead form (29 runs, 5 June to 7 July 2026), and incidents get a written post-mortem.
Let a co-owner prototype, then harden it before real client details go through it
The brokers needed a better way to collect client details before an appointment. Between 10 and 13 April, one co-owner built the first version himself with AI: 38 commits, a multi-step intake form with an admin dashboard. It worked, but it had 85 files and no tests, and its sessions and data access needed tightening.
From the next day I used AI tools to harden it for production.
- Magic-link sign-in hardened, with every submission bound to the session that opened it.
- Accessibility fixes, including a fallback for the signature step.
- Test suites, now 50 test files.
- Address autocomplete from the national address file (G-NAF).
- Logging, alerts and written runbooks for deployment.
The owner prototypes and I harden. I made 152 of its 201 commits.
Give the team’s AI a scoped key into the CMS, and keep a person on sign-off
I added an API to the content system so the team’s AI tools can edit content directly. Keys can edit pages, media and menus. Leads and users stay behind a human login. Changes made through the API are checked, and a person signs them off.
The team’s AI drafts articles against a fact base of 2,556 lender-policy facts across 34 lenders.

Recurring jobs run plan, do, check, approve
The weekly newsletter shows the pattern.
- Person plansThe content editor writes a short brief.
- AI draftsA scheduled Claude task drafts in the house voice.
- AI checksThe task checks every figure and link against its source.
- Person approvesA person reviews the draft.
Before each edition the task loads a style guide, a topic log and the latest drafts. It saves the draft with a short summary of sources, which items came from the brief and anything borderline, so the reviewer can see what to check.
How this was made
- What the AI did
- Assisted on roughly 60 to 90% of the website’s merged work changes (Claude, Codex and GLM) and drafted the weekly newsletter (15 drafts, 8 May to 21 Aug 2026).
- What I did
- Set the guardrails and the CMS key’s limits, hardened the intake app, and tried each tool on real work.
- Where a person signs off
- Releases, newsletter drafts and AI edits to the CMS each wait for a person.
I direct AI agents the way I used to run Scrum teams: bounded tasks, written rules and review gates, with a person deciding what ships. That’s how most of this was built.
What the figures count
The website shipped 592 merged work changes between December 2025 and September 2026. The monthly count rose from 17 in February to 174 in September. Roughly 60 to 90% were AI-assisted, depending on how you count, and nearly half (295 of 592) by branch naming alone.
Merged website changes per month, February to September 2026
Scope of the counts
- Business results. The figures count changes shipped, not leads, rankings or revenue.
- AI involvement. A branch name or co-author tag shows AI took part, not how much.
- Authorship. The counts include every merged change, including another developer’s. That developer started the codebase in December 2025, and my first commit was in February 2026.
- Type of change. More than half of the 592 are fixes.
Bringing this to another team, I’d start with one job per person and the guardrails first
This fits any team keen on AI in engineering that hasn’t yet brought the rest of the business along.
- Listen and measure. List the jobs people repeat, find who’s already experimenting, and time each job today.
- Pick one job per person. Write down who sets the brief, what the AI drafts, what gets checked and who signs off. Give it the rules and house style to work from.
- Put the guardrails in first. Business accounts only, read-only access where possible, a written list of what AI does not do alone, and an audit trail.
- Test before trusting. Run each job against past cases with known answers before it touches live work.
- Review with numbers. Time per job against the baseline, and errors caught. Keep what works on a second real task and drop the rest.