Six Things I Built in Claude Code Instead of Buying a Tool

I built six things in Claude Code this week that an agency would normally need a developer for.

1. Custom content briefs. One of the agencies I advise was spending two to three hours to produce a single content brief. It takes about 30 minutes now, and most of that is a human reading it and pushing back. We’re piloting it on one account before we roll it out portfolio-wide.

2. Simulated job candidates. A client is hiring a Director of Client Services, so we wrote the job post and then I put it in front of ten simulated candidates, each one a profile of a great-fit applicant. In under three minutes I had ten “people” telling me what landed and what they’d push back on.

3. Interactive pitch canvas. I was helping one of my agencies pitch a new program to a client. In a deck it becomes 30 slides nobody sits through. On a canvas the secondary detail stays hidden until somebody asks for it, and the conversation stays on the program instead of the page count.

4. Clickable website mockup. I’d been working on the new website messaging and UI/UX for one of my agencies, and instead of handing the developer a wall of copy in a doc, I built a prototype of the pages instead. Real copy, real structure, working links, live on a URL a few hours after the call. I have no design skills.

5. Content repurposing pipeline. I migrated my LinkedIn content scout off the Chrome MCP over to the AuthoredUp MCP, so I get a more stable build and better insights informing the system. Then every high engagement post gets built as an article in my voice, picks up a featured image rendered off my brand template via the Figma MCP, and gets published to my website automatically via the WordPress API.

6. A scout that builds me skills. Once a week it reviews my own Claude sessions looking for work I frequently repeat. The first thing it found was me running the same post-call recap over and over from scratch. So it built the /debrief skill that I use to keep work moving same-day instead of later that week.

The tool was never the hard part

Every agency owner I talk to asks which AI tool they should buy. I don’t think that’s the question.

Nothing above came out of a box. I built all six because I’m the one doing the work, so I knew exactly what each one needed to do.

That is the whole advantage and it has almost nothing to do with being technical. I’m not. The content brief tool works because I have written and rejected a few hundred content briefs, and I know which part of that job is judgment and which part is assembly. Somebody who has never sat through that argument with a writer can’t spec it, no matter how good they are at building software.

So the constraint on all six was never engineering. It was proximity. The person who feels the friction has to be the one describing the fix, in enough detail that it survives contact with a real account.

Where buying is still the right call

I’m not telling anyone to stop buying software. Most of what an agency runs on should be bought. Accounting, payroll, storage, the email platform, the file everybody works out of. Somebody else’s workflow is fine for all of it, and building your own version would waste a year.

The line falls where the tool starts encoding how you work. A project management tool that arrives with an opinion about how a project moves is fine right up until your delivery model is the thing clients are paying for. Then you either bend the work to the tool or you spend every quarter fighting the defaults.

And when you buy for a process you haven’t defined yet, you don’t get a solution. You get the vendor’s definition of your process, installed, with your team trained on it. I’ve seen a reporting platform rollout run fourteen months, and most of that was not the software. It was an agency working out what it actually wanted to say to clients, in public, in front of a vendor, at the worst possible time to be figuring it out.

The honest version

The content brief tool is running on one account, not the whole portfolio, and it stays there until the people using it every day tell me it holds up. Some of what I build gets thrown out inside a week. That’s fine, because finding out cost an afternoon.

That’s the part that actually changed. Not that I got good at building software. The distance between noticing a problem and testing a fix collapsed to about an afternoon. When that distance was three weeks and a developer’s time, you only fixed problems big enough to justify a ticket. Most agency friction isn’t that big. It’s the two hours a week that nobody escalates, on eleven different things, and it never adds up anywhere a person can see it.

So when someone asks me which tool to buy, I ask what part of their week they’d fix if fixing it cost an afternoon. Most of the time the answer isn’t something anybody sells.

Post format inspired by Emily Kramer.