Should You Build Your Own Software for Your Agency?

Can an agency really build its own software now?

Yes. AI has become good enough that the average person can bring at least an initial version of a piece of software to life. In theory you could replace most of what you pay for today.

We proved this on a harder example than usual. We built our own dialer for our setters, which actually places calls to live people. Most agency builds in this space are project management tools, client portals or reporting dashboards. A dialer integrates with a CRM and a phone provider, so it is more complicated than a tool that only collects data. It was still doable with the help of AI.

What does an agency dialer include?

Ours grew into more than a dialer. It tracks bookings automatically, keeps call logs of everything the setters do, and has score cards that compare each setter with the rest of the team. It also has a campaign section where the script can be edited.

The dialer itself has a parallel dialer and a power dialer, with a script that changes dynamically depending on who is being spoken to, plus quick buttons to find the right answers to objections.

Why did we build our own dialer?

There were three main reasons, and they are a useful checklist for any tool you are considering.

First, small features specific to our use case. Examples were an integration with GoHighLevel, easy access to the stats we care about, and a custom script. Off the shelf software has to suit many kinds of agency, so it leaves out details that matter to one. When you build your own, you tailor it to how you work.

Second, cost. Dialer plans were priced per user, and the higher plans with the features we wanted cost far more per setter. The bill grows as the team grows. It got to the point where it created friction: it made us less keen to trial new setters, because each trial meant paying for another seat on software we were not happy with.

Third, features the tools we tested simply did not offer, or offered only in part. We wanted parallel dialing in a specific way, confirmation calls on no shows built into the setter's flow, and no shows added back into the queue from the booking system. We did not build it because we could. We built it because it made us more effective and let us hire less.

How do you build an internal tool with AI?

We did not follow a complicated process. It is the same approach used in our other builds, such as a media buyer, a project management system or a reporting dashboard.

1. Open Claude Code, or the AI you prefer.
2. Record a long voice note describing what you want, what you like, what you do not like and everything you need.
3. Have a conversation with the AI about it, rather than writing a rigid specification.
4. Record a screen share video of the tools you already use, saying what you like and dislike about each one. Upload it and ask the AI to transcribe it and analyse it frame by frame.
5. Add screenshots as references. Seeing the thing you describe, such as a loading animation you dislike, gives the AI more context.
6. Within a few days you have a first version your team can use.

Why should you ship version one fast?

A first version in a few days, given to the sales team straight away, beats a month spent planning the perfect tool. A month of scoping, agreeing a feature list and building before anyone sees it often ends with a first test on day 30 that might not even be good. Shipping version one early means that by day 30 you have a tool shaped by real use.

The version people use today is the worst version it will ever be. It will have bugs and look rough. That is fine, as long as it does not damage the business. Treat it as a beta and collect feedback every day. Sort the feedback into things to build now, and things that are only somewhat important. Not all feedback is relevant, so focus on high leverage changes, and fix bugs that stop people using it quickly.

Many of the best features in our dialer came from the users. The script that changes by prospect, the quick buttons for objections, the score review, the pay section and the training card were all their ideas.

When should you not build your own software?

The most important rule is to ask what problem you are actually solving. Most businesses have one thing that is truly slowing growth. Your job is to focus on that constraint. If building a tool is not addressing it, we would probably not do it.

Some examples: with only one client, you do not need a complex client reporting system. With no projects running, you do not need a project management tool. If you are happy with your dialer and it does everything you need, you do not need to build another one.

We could replace many of the tools we pay for, but that does not mean we do. Building for the sake of building is a rabbit hole. You can end up with several half finished tools that look good and are not very functional, and that time is usually better spent elsewhere. A side project for fun is fine, as long as you know it is not solving a constraint.

It is also worth remembering that an internal tool is different from software sold to many companies. It works well for us because it is built around how our team works. Software that many different people use, in many conditions, is a more complicated job than adding more users.