AI agents are the cheapest senior developers you will ever hire.
They are also the most expensive ones.
Both of those are true, and which one you end up with has almost nothing to do with the model you picked.
We build CloseBot with AI in the loop every single day. Our platform processes north of 150,000 messages a day for agencies and their clients. So this is not a “AI coding is fake” post. AI writes a lot of our code – big Claude Code fan here. It is genuinely astonishing.
AI in the Loop is a key phrase there…
AI in the Loop = Human in the Loop → AI generated code reviewed by humans that understand the full roadmap, scaling needs now & future, and things not provided in context
Humans at CloseBot (really smart ones) review, discuss, and often modify every piece of code written by AI. I’ll explain below why this is essential.
Because a lot of agency owners are currently sitting in front of Claude or Cursor thinking
why am I paying for an AI appointment setter when I could just build one.
You probably can get close… You could probably spend a couple of months building a CloseBot replacement that checks all the boxes. Getting 90% of the way there is the cheap part. It’s easy to get something together that works in testing and under light load. But there are three ways it goes wrong that are all the same mistake wearing different hats. And the sum of those mistakes ends up costing you and your clients way more in missed revenue opportunity than it’s worth.
That mistake is this: the AI doesn’t know what you don’t tell it
Let’s look at three scenarios…
1: You overscoped it, and now your hosting bill is a car payment
“Build this so it can scale.”
This feels responsible. Feels grown up to type the word “scale”… Feels like something a real CTO would say. You are thinking ahead. Good for you.
Watch what happens.
The AI has now been told that scale is the priority. So it gives you scale. It gives you a message queue. It gives you a Redis layer for caching. It splits your app into services so they can be deployed independently. It containerizes everything and hands you a Kubernetes config because that is what “scalable” looks like in the training data. Maybe it adds a read replica for your database, because reads should not compete with writes at scale. Maybe it sets up a separate worker fleet for background jobs.
Every single one of those decisions is correct.
For a company with 400,000 users.
You have eleven. Nine of them are your own test accounts and one is your mom.
Your $12 a month app is now a $600 a month app, and it will keep being a $600 a month app while you have eleven users, because idle infrastructure does not care that it is idle. You are paying rent on a warehouse to store a sandwich.
And the cost is not just the hosting invoice. It is the debugging. When something breaks in a single boring app on a single boring server, you look at one log. When something breaks across five services talking to each other through a queue, you get to learn about distributed tracing at 11pm on a Saturday while a client texts you asking why their leads stopped getting replies.
The AI did not do anything wrong. It cannot see your Stripe dashboard. It does not know if “scale” means 50 conversations a day or 50,000. You said scale, it heard scale, and it built for scale.
What to do instead: put actual numbers in your scope of work. Not adjectives. Numbers.
“We will have 20 agency accounts in month one, maybe 200 by month twelve. Each one handles roughly 300 inbound messages a day. Build the simplest thing that handles 200 accounts, run it on one server, and tell me the specific point where this design falls over so I know what to watch for. We expect to grow to 100 agency accounts within the first 3 months, so build in a way that’s easy to scale later.”
Human in the Loop: Human reviewers will understand things you failed to mention to your AI. They will see areas that are overbuilt for where they know you want to go, and be able to tweak things before it hits production and your bills skyrocket.
Real Story from My Own Past…
When CloseBot was initially built, there was no AI. That didn’t stop me from learning about this mistake. Gerald and I were the first real CloseBot users back in 2019…
I noticed the app was slow, so I increased the database capacity until it seemed fast… the result was a $1,200 bill after 1 month, just for the database… and it still crashed while on family vacation (wife was not happy).
The real solution was better indexes on the database table columns to match queries that were hit frequently.
2: You never mentioned the roadmap, so it built you a wall
This one hurts.
You ask for version one. Just get something working. You are an agency, you want to book appointments for one client to prove it works, then roll it out to everybody.
The AI builds you a beautiful version one.
It builds it for one client.
Nowhere in your request did the words “multi-tenant” appear. So there is no account ID on your conversations table. Your lead statuses are hardcoded in three different files. Your calendar connection is a single set of credentials in an environment variable. Your timezone is whatever the server’s timezone happens to be, which is UTC, which nobody has ever lived in 😂
Works perfectly. Your one client is thrilled. You go sell it to nine more clients.
And now you need to add an account ID to a table with two million rows in it, backfill every existing row, add an index so lookups do not take nine seconds, and do it all without your live automations going dark.
I wrote about this exact thing recently and it is worth repeating, because it is the single most common way people take their own platform down. Adding an index to a large table on a live production database can lock that table. Potentially for hours. And while it is locked, nothing else touches it. Not your dashboard, not your follow-up sequences, not the automation that was supposed to reply to a lead within thirty seconds. Everything you built sits there frozen while your users watch a spinner.
The conversation that gets you there sounds like this:
“Why is my dashboard slow?”
“Your conversations table has no index on account_id, so every lookup scans the entire table.”
I have no idea what that means. Fix it, I have customers paying me
Six words and a shrug that brings your entire system offline as your database tries desperately to add indexes postmortem.
There are safe ways to do all of this. Concurrent index builds, backfilling in batches, adding the column as nullable first and filling it in behind the scenes, expand-and-contract migrations. Your AI knows all of these techniques cold. It will happily walk you through them. It will not choose them on its own, because “add an index” is a one-line answer and it gave you the one-line answer you requested.
What to do instead: tell it the future before you build the present.
“Version one is one client. By month three I need this to serve 50 clients under one dashboard, each with their own calendar and their own AI persona. Build v1 simple, but do not paint me into a corner on multi-tenancy. Where are you making assumptions today that will be painful to undo?”
Human in the Loop: Human reviewers will see these mistakes immediately… these are the basic principles their education is built on. They would edit the database structure and code from the beginning to make it capable of handling multiple users from the start, so it’s not a massive problem later.
And separately, whenever a change touches the database: ask for the migration plan as its own thing. Not bundled into the feature. A written plan, in plain English, that says what happens to live traffic while the change runs. If the answer contains the words “brief downtime,” you get to decide if brief means eleven seconds or forty minutes, which are extremely different numbers when leads are coming in.
Real Story from My Own Past…
Continuing on the story from above where I realized I needed better indexes.
Well, I eventually added those indexes, and everything stopped cold. Not just the dashboards that were slow… EVERYTHING.
You see, when your database goes down, the heart of your app is taken offline. Nothing works. And in my case, it was down for 4 hours on the weekend. In addition to my $1,200 bill I (and my 1 user) were missing AI appointments from being set, thus losing revenue.
Starting to see how replacing a $97/month subscription can end up costing you thousands?
Alexa, how long would it take me to recoup $97/month savings with an upfront cost of $10,000? <Alexa> Approximately 8.6 years is how long it would take to recoup your initial investment of $10,000 at $97/month in savings
3: You Build the Features You Want Instead of the Features You Need
There is a quote everybody attributes to Henry Ford, which he almost certainly never said, about how if he had asked people what they wanted they would have asked for a faster horse.
Whether true or not, this is the most useful thing you can keep in your head while building software with AI.
Because an AI agent is the greatest order-taker ever created, it has almost no product opinion. It has no idea where your industry is heading. It has never sat on a sales call. Ask it for a faster horse and it will build you a magnificent horse, thoroughbred bloodline, custom saddle, beautiful documentation. It will never once look up and ask whether anybody is going to be riding horses in eighteen months.
Now stack that on top of the fact that your users are also asking for faster horses. People describe the pain they have today using the vocabulary of the tool they already use. Nobody submits a feature request for a category that does not exist yet.
So you end up with two order-takers wearing one trench coat. Your customer asks for a faster horse, you relay the request, the AI ships the horse, everybody claps, and at no point in that chain did a single participant ask whether horses were the right decision in the first place.
Real Story from My Own Past…
For about a year, the most requested feature at CloseBot was looping objectives. Everyone wanted it. Competitors were shipping it. Every demo call had somebody asking for it. It was the clearest possible product signal, and building it would have been easy and popular.
We did not build it, because we were fairly sure the entire concept had an expiration date on it. Rigid objective loops were a workaround for models that could not hold context and make judgment calls. Models got better. The workaround was going to become dead weight, and worse, dead weight our customers would have built their entire client onboarding around.
So we built Agent Node instead. 0 feature requests for it, but now the foundation of CloseBot.
The other half of this is that you cannot guess your way to a roadmap, so we stopped guessing. We went and looked at what 1.1 million booked appointments actually show about follow-up timing, message cadence, and what separates the agencies booking at 4 percent from the ones booking at 0.4 percent. This is something software companies have access to that you do not… If you build your own, you’re flying blind.
And this is the part that matters most: we do not publish that research and leave you to implement it. We ship it into the product as defaults and as hard-prompting underneath every agent. So when a CloseBot user builds a bot, they get the behavior that worked across a million appointments whether or not they ever read a benchmark report in their life.
An AI dev agent cannot do that for you. Not because it is not smart enough, but because the data does not exist in its training. Nobody published your niche’s conversion numbers. There is no Stack Overflow answer for “how many follow-ups before a chiropractic lead goes cold.”
What to do instead: keep two lists and never let them touch.
One list is what hurts today, sourced from your users. Hand that one to the AI all day long, it is fantastic at it. The other list is where this is going in eighteen months, and that one is yours. You do not get to delegate it, and you definitely do not get to crowdsource it.
Then before you commit to anything on either list, ask one question out loud: what would make this feature obsolete? If the honest answer is “the next model release,” go build something else.
So should you build your own AI appointment setter?
No is almost always the answer. Building a shallow solution like a general-purpose CRM is one thing, but building something with depth in a single category (like CloseBot with AI appointment setting) is much more difficult and costly.
It will cost you in hosting costs, maintenance time and mistakes that ruin bookings.
If you do choose to build your own software… be honest about what you are buying with those months of time. Building software is guaranteed to draw your focus away from what’s earning you revenue today… and it can potentially kill your existing business as your attention and vision becomes split.
Building CloseBot is what killed my real estate business because of drawn focus and resources. I’m ok with that now, but are you?
The reason I can write this post is that we have already paid for these lessons. Every single one of them. CloseBot handles the message volume, the follow-up state, the timezone mess, the retry logic, the double-send prevention, the GoHighLevel and HubSpot plumbing, and roughly nine hundred edge cases that only appear when you are running a hundred and fifty thousand messages a day and cannot afford to guess. We built the boring infrastructure so you can spend your time on the thing your clients actually pay you for, which is booked appointments and a good offer.
If your goal is to sell appointment setting, buy the appointment setter and go sell.
If your goal is to build software, build software, and go in with your eyes open.
Summary
There is no magic prompt. I get asked for one constantly and it does not exist.
The only real answer is that you have to understand the decisions your AI is making, or you have to hire someone who does, or you have to buy something built by people who already did. Those are your three (good) options.
Skip all three and the app will still ship. It will look great. Your clients will love it.
And somewhere in there, a timer you cannot see is already counting down the days until everything comes crashing down.
FAQ
Yes, you can build a working AI appointment setter with tools like Claude Code or Cursor, and many agency owners have. It will cost more, be less reliable, book less appointments and further behind in ongoing features. The build is not the hard part. The hard part is the ongoing ownership: calendar API changes, retry and duplicate-message handling, timezone edge cases, opt-out compliance, and database migrations that have to run without taking live automations offline. Budget for the maintenance, not the prototype.
When you use a software off the shelf, large hosting costs are shared amongst all the users. AI-generated software gets expensive to host when the scope of work asks for scale without giving numbers. Told to “build for scale,” an AI agent will reasonably add queues, caching layers, container orchestration, read replicas, and separate worker fleets, all of which cost money whether or not anyone is using them. Give it real volume expectations instead, and the same feature runs on a fraction of the infrastructure.
Technical debt in AI-generated code is any shortcut that works today and blocks a change you need tomorrow. Common examples include tables with no tenant or account ID, hardcoded statuses spread across multiple files, single-tenant credential handling, and conversation state kept in memory. None of it is broken code. It is correct code for the smaller problem you described, which becomes a rewrite once the problem grows.
Adding an index to a large table on a live production database can lock that table while the index builds, which on a multi-million-row table can take hours instead of seconds. During the lock, everything that touches the table stops, including dashboards, follow-up sequences, and automations. Safe alternatives exist, such as concurrent index builds and batched backfills, but an AI agent will not choose them unless asked.
Buy it if your business model is selling appointments, and build it if your business model is selling software. Building makes sense when you have in-house engineering capability, a workflow nothing on the market handles, and the willingness to own the product permanently. For most agencies, the months spent building and maintaining are months not spent selling, which is the actual cost.
A scope of work for an AI coding agent should include expected volume in real numbers, the roadmap for the next twelve months, and a request for the tradeoffs it made. Say how many accounts and messages per day you expect at launch and in a year, name the features you know are coming, and ask two questions every time: where does this design break, and what did you deliberately not build?
You do not need to write code to build software with AI, but you do need to be able to evaluate the decisions it makes, or hire someone who can. At CloseBot, understanding software architecture catches roughly one AI mistake per feature, and the engineering team catches about five more before anything reaches production. Shipping software for resale with nobody in that reviewer role is the risk.
CloseBot built Agent Node because looping objectives were a workaround for older models that could not hold context and make judgment calls, and that limitation was disappearing. Looping objectives were the most requested feature at the time. Building them would have meant customers structuring entire client onboarding processes around a pattern with an expiration date on it, so CloseBot built for where the models were heading instead.
You research outcomes instead of collecting feature requests. CloseBot analyzed 1.1 million booked appointments to identify what actually drives booking rates, including follow-up timing and message cadence, then shipped those findings into the product as defaults and system-level prompting. Feature requests describe the pain users have today. Outcome data shows what to build next.