This site is built and operated by a multi-agent Claude Code delivery team working a real Jira backlog, RICE-scored through Jira Product Discovery and gated through UAT before anything reaches production.
→ Multi-agent delivery team, RICE-scored backlog, UAT gate enforced on every release.
Problem
A portfolio site built by hand, one page at a time, does not demonstrate anything about how I actually work as a product owner. I wanted the site itself to be the evidence, a live example of running a product delivery function, complete with a backlog, prioritisation, specialist roles, and a release gate, rather than just a static description of that experience written in prose elsewhere on the site.
Context
I set this up as a real operating model, not a demo. Ideas get captured, scored, and prioritised. Work gets assigned to specialist roles with defined remits. Nothing reaches the live production site without going through a review gate I control. The fact that the specialist roles are AI agents rather than human colleagues does not change the discipline the process demands, if anything it means the process has to be more explicit, since there is no shared context an agent already carries between sessions.
Business objective
Run this site as a genuine product, with a backlog, a prioritisation framework, and a release process, so the site's own operating model is itself a demonstration of the way I approach digital platform ownership.
Customer/user objective
A hiring manager or recruiter looking at this site should be able to see, not just read about, how I structure delivery, how ideas get triaged, how specialist work gets divided, and how quality gets checked before anything ships.
Constraints
Every specialist role on this project is an AI agent with no memory between sessions unless I deliberately persist context for it. That meant the operating model itself, not just the code, had to be documented clearly enough that a fresh agent could pick up a ticket correctly without me re-explaining the same context every time. Nothing was allowed to reach the production domain without my explicit review, which meant building a real uat environment and treating it as a genuine gate, not a formality.
Stakeholders
Me, as the sole product owner and the only human reviewer in the loop, and a set of specialist AI agents each scoped to a specific remit, frontend and backend engineering, QA, UX review, copywriting, legal and GDPR review, SEO, analytics, and periodic reconciliation between the different tracking systems.
Research and discovery
I mapped out what a real product delivery operating model needed, an idea intake process, a prioritisation framework, clearly scoped specialist roles, and a release gate. I then worked out which of those needed a dedicated tool, Jira for backlog and prioritisation, Monday.com for a stakeholder-facing view, Confluence for documentation, versus which could be handled by process alone.
Options considered
One option was a single general-purpose agent handling everything end to end. I chose a multi-agent structure instead, with named specialist roles and defined remits, mirroring how a real delivery team is structured, because a single agent handling frontend, legal review, and SEO all at once has no natural check on its own blind spots the way separate specialists reviewing each other's work do.
Prioritisation
I prioritised getting the backlog and release gate working correctly before investing in anything more sophisticated, since a fast multi-agent team building against an ungoverned backlog, with no review gate before production, would have been a liability, not an asset.
Delivery
I built a RICE-based prioritisation framework and used Jira Product Discovery to score every idea before it became committed work in a separate Jira execution board. A Scrum Master role orchestrates specialist agents against that backlog, frontend and backend engineering, QA, UX review, copywriting, legal and GDPR review, SEO, analytics, and periodic reconciliation between Jira, Monday.com, and Confluence so the three do not drift apart silently. Every change ships to a staging environment first and only reaches the live production site once I have reviewed it there directly.
Decisions made
The decision to enforce a genuine uat gate, rather than letting agents push straight to production once their own checks passed, was the one that mattered most. Agents are fast and generally accurate, but fast and generally accurate is not the same as always correct, and a personal brand site is exactly the wrong place to discover the gap between those two things after the fact. I also decided to give each agent a narrow, named remit rather than one general-purpose agent doing everything, so review responsibilities stayed clear.
Trade-offs
Running a full multi-agent pipeline with a review gate is slower per change than letting an agent push directly to production. I accepted that trade because the site is a public representation of how I work, and a visible mistake there costs more than the time saved by skipping review.
Business outcome
The site runs on a real backlog with RICE-scored prioritisation, specialist delivery roles, and a UAT gate before production, the same operating discipline described in the case studies elsewhere on this site, applied to the site itself.
Customer outcome
Anyone reviewing this site as part of a hiring process can see the operating model behind it directly, rather than relying solely on my account of how I approach platform ownership.
Lessons learned
The hardest part of running an AI delivery team is not the individual agents, it is the operating model that keeps their work coherent across sessions with no shared memory. Explicit process, clear remits, and a real release gate matter more with AI agents than with a human team, not less, because there is no informal shared context to fall back on when the documented process has a gap.
What I'd improve today
I would formalise the reconciliation between Jira, Monday.com, and Confluence earlier, since documentation and stakeholder-facing views drifting out of sync with the actual backlog was a real failure mode this build ran into, not a hypothetical one.
Site architecture
How this site is actually built.
Claude Code orchestrates a team of specialist agents against a Jira backlog, publishing through the same infrastructure shown below. Select a node for details.
Orchestration
Specialist agents
Delivery infrastructure & publishing
