Three steps from the ticket queue to a website your team runs.

Keep them. The backlog is real and someone should clear it. Discovery is about the layer above: whether the system creating that backlog is the one to invest another year in. The roadmap will make your freelancer more useful, not redundant.

They could, the way your accountant could do your marketing. Your engineers are building your product, and every hour on the website is an hour off the roadmap. An agentic website is built so they never have to touch the site again. Marketing runs the site, engineering stays on the product, and the guardrails keep everyone safe. And because it's plain files in a repo, engineering can still read every change whenever they want to, without owning any of it.

Nothing, for the way the web used to be run. Platforms made sense when code was expensive: you traded ownership for not needing developers. That trade has ended, and what's left on your side of the deal is the limits. The one that matters now is your agent. It wants to read the files and change them, and a platform doesn't let it. Some now offer an MCP or an API so an agent can reach in, but that's an agent working through a keyhole: it can't see the whole site, can't run it, can't check its own work before it ships. When you don't own the code, your agent is a guest, not an editor. Whether that matters for you yet is exactly what Discovery works out.

Less than the ticket queue takes now. Discovery is one working call, and we've read your site before it. During Transformation your team reviews what shipped on the live preview every fortnight and answers questions as they come up; the design and the build are ours. After handover it's the monthly session, plus the changes your team was going to make anyway, now made by briefing the agent instead of writing a ticket.

You ask. Run & Grow has a guide on call: a person who knows your site, your rails and the tools, for the moment the agent does something unexpected or a change needs a second pair of eyes. Most of what comes up becomes a playbook or a new skill in the repo, so the next person doesn't get stuck on the same thing. And because every change lives in the repo's history, undoing one is a playbook item, not an emergency.

Media lives in a managed asset pipeline that ships as part of every build: purpose-built storage, optimised and delivered automatically. Your team drags an image in; where it physically lives is infrastructure, and infrastructure is our job. Nothing about the stack is roll-your-own. It is boring, battle-tested parts, deployed for you and supported by us. You were never editing images inside your CMS's database either.

You could get a long way, and some teams have. Point Claude or Cursor at a site and you'll get a page. The hard part is the second year. If nothing in the code tells the agent what your brand is, which components exist or what finished looks like, it reinvents the stack every session, the tenth page doesn't match the first, and you end up with a codebase nobody would choose to inherit. What we add is the part that stops the drift: the brand encoded, our standards as guardrails and skills, the machine layer, and a team trained to run it safely. The roadmap will show you which parts you genuinely can do in-house.

A reputation we want: the partner who hands over the keys. Most people who see the plan want the people who drew it to build it. Some don't, and that is fine too.