How to Build AI Internal Tools Your Agency Team Will Use

Why do internal tools go unused?

The barrier used to be time and cost. With AI that barrier is largely gone. The new barrier is knowing which of the many things you could build is worth building. Out of everything possible, perhaps only a handful will move the agency forward and help the team.

Most internal tools fail for the same reason: someone built the thing that was easy to build instead of the thing slowing delivery down. The process below is the one we follow for the tools we build for agencies, from QA checkers and progress reports to health scoring, content systems and larger operating systems with team views and client portals.

Step 1: How do you find the problem to solve?

Do not ask the team what tool they want. Ask what problems they currently face in client delivery. Useful questions include what their day to day looks like, what would break first if you onboarded 10 clients tomorrow, and whether you could cope with the workload if five new clients arrived.

Look for the constraint, not the complaint. In most delivery processes one stage slows everything down, and that stage decides what to build next. If the process runs onboarding, research, production, and research is the slow part, a quality approval tool will not help, because it is not the constraint.

Once you name the constraint, the build tends to name itself. If research takes two days before anything gets made, you need a research engine that pulls and ranks competitors. If too many revisions bounce back from clients, you need a QA bot. The problem is the specification for the build, so spend the most time here. Talk to your team, because they see the work on the ground.

Step 2: How do you choose the solution?

One constraint can be solved in many ways. If research takes two days before every client shoot, you could hire another researcher, build a bot that automates the whole research document, set up shared files everyone fills in, or build a research tool that gathers and ranks competitors and breaks them down for the account manager.

Especially at the start, full automation is usually the wrong instinct. If you remove the human completely, quality and consistency tend to drop, and context about the client is lost. Instead, arm the team. Find the work a person does not need to do, let a tool handle it, and leave people to focus on the part that drives revenue.

The rule that matters: client experience has to survive the tool. If service gets worse because of it, the tool has failed. Automating most of someone's work while keeping quality the same or better is better than a full automation that does not work.

Common areas to look at are reporting, research, client communication, QA, content management, health scoring and onboarding. Your own list should come from your own problems.

What does a good example look like?

One agency spent a long time preparing research for clients and prospects. Their team had to watch many Instagram Reels, transcribe them and find the hooks. We built a tool where you enter a username. It scrapes Instagram for a set period such as 30 to 60 days, finds the Reels, ranks them by engagement, and for the top few runs a frame by frame analysis of the video.

It reports the hook, the visual hook, the transcript, why the video performs well and the format, then says how to apply it to that client's brand. A human still gives input and makes the recommendation. The tool packages the information so the person starts with insight rather than a blank page.

Step 3: What stack should you build with?

Most of our builds use the same four pieces. You can swap any of them, since AI coding agents change quickly. The point is that something coding the tool for you works with the rest of your set up.

Connect to the software your team already uses. If they work in Notion, use the Notion API. If they use Asana, Jira or GoHighLevel, connect to those rather than building something separate. Most tools have an API or an MCP, and a tool that sits inside the existing workflow is far easier to adopt.

• Supabase for the back end: it stores data in tables and handles authentication.
• Railway for deployment, so the tool is live and your team can log in from different computers.
• GitHub for the code, a bit like a Google Drive for code, with version control.
• Claude Code to build everything, or another AI coding agent.
• The AI provider's API, such as Anthropic, for any AI features.
• APIs for your team's existing tools, such as Notion, Slack, Calendly or Asana.

How do you prompt the build?

You do not need technical language. Explain the problem, describe the solution you think will work, mention the tools you already use, and ask for a plan. It works like talking to a person. You do not have to name frameworks or languages.

The earlier steps matter because they define the prompt. AI will build whatever you ask, but it only builds something useful if you spent time on the problem first.

To try it, download the Claude Code desktop app, open the code section, start a new project and select a local folder. Turn on the microphone option, describe your problem, solution and tools, ask for a plan, switch on plan mode and send it. Getting a first proof of concept is straightforward. Getting a version live for a team is more complicated.

Step 4: Why launch a rough V1?

Do not spend a long time chasing perfection. Launch a first version as soon as possible and tell the team it is the worst version it will ever be. It may have bugs and look rough. A rough version in the team's hands beats a perfect one in your head, because a long private build gives zero real feedback. A tool shipped early will collect feedback and improve over several versions in the time a perfect build would take.

Still avoid bugs and any security problems. V1 should solve one specific problem, and the only test is whether a person can use it to make that original problem smaller. Resist the temptation to add features.

Steps 5 and 6: How do you collect feedback and refine?

Feedback is the step most people skip because it is uncomfortable. Testing the tool yourself is not the same as your team using it. They will use features differently from how you expect, and they may break things.

One of the best things we have done is put a feedback button inside the tool. Pressing it sends a message straight to you, so there is less friction than recording a video. Be transparent with the team, say the more feedback the better, and frame it as making their work easier, not replacing them. Some teams run small competitions or ask each person for one piece of feedback a day.

To act on feedback, open the project in Claude Code and say what the team reported, for example that comments are not opening properly and the interface is weak, then ask for a plan.

Not every note deserves a build. For each request ask: does this get us closer to solving the original problem? If not, do not build it. A request for a 3D interactive map, for example, does not help a reporting problem. Park it as a future feature.

Then repeat the cycle: launch, collect feedback, refine, release. Some of our tools reach version 10 or beyond. Simple reporting tools can grow into full operating systems as new problems are added. Expect early versions to look wrong and have bugs. That is the loop working.

Which final test should every tool pass?

Before or after building, ask three questions. Does this make the agency money? Does it help keep a client? Does it give the team hours back? If the answer to all three is no, do not build it. The goal is a tool your team opens every morning, which lets the existing team do more without hiring at every stage of growth.