Skip to content

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.

Role
Set up the guardrails, hardened the intake app, added the CMS API key
Client
A Brisbane mortgage brokerage
Timeline
2025 to 2026
State
In use

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.

A mortgage guide page on the rebuilt website, with a table of contents beside plain-English sections
A guide page on the rebuilt website. The team’s AI tools draft content like this, and a person signs it off.

Recurring jobs run plan, do, check, approve

The weekly newsletter shows the pattern.

  1. Person plansThe content editor writes a short brief.
  2. AI draftsA scheduled Claude task drafts in the house voice.
  3. AI checksThe task checks every figure and link against its source.
  4. 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

  • Feb17 (16 AI)
  • Mar0 (0 AI)
  • Apr37 (26 AI)
  • May0 (0 AI)
  • Jun81 (75 AI)
  • Jul136 (115 AI)
  • Aug147 (131 AI)
  • Sep174 (167 AI)
Merged pull requests to the website repository, excluding release and sync merges. AI-assisted uses the widest count, an AI branch name or co-author tag. Counted 30 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.

  1. Listen and measure. List the jobs people repeat, find who’s already experimenting, and time each job today.
  2. 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.
  3. 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.
  4. Test before trusting. Run each job against past cases with known answers before it touches live work.
  5. Review with numbers. Time per job against the baseline, and errors caught. Keep what works on a second real task and drop the rest.

The playbook

Appendix. The reusable material from this work, for readers who want it. The case study above stands without it.

Seven kinds of work AI took on

Kind of workWhat it didScale
Scheduled reportingDaily website, search, YouTube and CRM figures; lead and growth dashboards; meeting packs for the owners; site audits315 collection runs, March to July 2026 (310 completed)
WatchersA daily test enquiry through each main lead form; lead watchers that checked for enquiries missing from the CRM after site changes; a property-email watcher; a rate and scheme change checkTest enquiry: 29 runs, 5 June to 7 July 2026
Content pipelinesWeekly newsletter drafts from an editor’s brief; a daily check on content edits; anonymised client stories; Google review replies in the brokerage’s voice15 weekly newsletter drafts (8 May to 21 Aug 2026); 38 edit-check runs (30 May to 14 Jul 2026)
Knowledge basesA lender-policy fact base, a voice guide and a story register that content work draws on2,556 facts across 34 lenders; 277 stories
Task dispatchA tag on a task sent it to Claude, which opened a pull request that Claude and Codex reviewed before a person approved it7 pull requests opened, 5 merged; retired 29 September 2026
AdminInbox triage, a CRM clean-up plan, a vendor offboarding checklistOne-off jobs
Guardrails on the AIRules for what counts as checked, an audit log of AI sessions, a limit on concurrent agent workers, written post-mortemsAudit log from 8 May 2026; 55 post-mortems

The adoption cycle for people new to AI

Engineers are usually the easy part. Everyone else comes round in stages, and each stage has a different worry to remove.

StageWhat they are thinkingWhat helpsAt the brokerage
1. Worried“Will this break something? Will it make me look careless?”Name the specific fear and build the guardrail for it firstDrafts, previews and publish rules came first
2. Receiving“I’ll look at what it produces.”AI output arrives in tools they already use, and they judge itMeeting packs and plain-English updates; daily content checks
3. Steering“It’s close, but it’s not how we’d say it.”Their corrections become written rules the AI followsThe editor’s brief steers the newsletter lineup
4. Doing, safely“I’ll try one real change.”A safety net they can see: drafts, previews, a sandboxThe principal editing and publishing pages himself
5. Building“I could make a tool for this.”Room to prototype, and someone to harden what they buildThe co-owner’s intake app; AI content work through the CMS API

People move at different speeds, and some stay at stage two, which is fine. The job at each stage is to remove that specific worry.

Six habits for getting more out of Cowork

Most people use AI as a chat box: ask, copy, paste, forget. The gains come from turning a job they repeat into a standing setup.

  1. One project per recurring job, with standing instructions: what good looks like, the house style, where the sources are, and what it must not do.
  2. Write a brief. State the outcome, the files it should use, the constraints and what counts as done.
  3. Connect only what the job needs, one connection at a time.
  4. Schedule the repeats. Once a job works twice by hand, make it a scheduled task that leaves a draft for review.
  5. Make feedback permanent. When you correct the same thing twice, write the correction into the instructions.
  6. Ask for the evidence. Every output should say what it used, what it checked, and what it is unsure of.

A real job spec

The newsletter task’s instruction set, shortened and anonymised.

Every Thursday 7am: draft this week’s newsletter for review. Audience: first-home buyers, who aren’t finance-savvy.

  1. Load the rules: style guide, topic log (no repeats from the last 3 editions), quality checklist, the 2 latest drafts.
  2. Read the content editor’s brief in the task tool. Treat it as steers for the lineup.
  3. Scan the inbox (last 10 days) for fresh property and finance data.
  4. Research first-party sources from the past 7 to 10 days.
  5. Pick 5 items, each from a different primary source.
  6. Verify. Check every number against the original page. Confirm every link loads. Don’t guess a URL.
  7. Draft in the house voice. Keep each item tight: one short paragraph and a one-line takeaway.
  8. Save the draft with a short summary: sources, which items came from the brief, anything borderline.

Don’t send anything. Don’t touch the CRM.

Hiring for an AI-native UI/UX role, or bringing AI into a team?

I’m open to AI-native product design and design-engineer roles, and to selected scoped consulting. Email is the quickest way to reach me.

Consulting enquiries