The question every large operator eventually asks
Once a property management company reaches a certain size, someone in leadership asks the question: the AI models are available to everyone now, our engineers are capable, so why pay a vendor when we could build this ourselves?
It is a reasonable question, and for a handful of operators the answer is genuinely build. But for most, the question undercounts what building actually involves. The visible cost of an AI leasing agent is a small fraction of the total cost of producing and maintaining one. This piece lays out the hidden costs honestly, so the decision is made with eyes open rather than on the seductive but incomplete logic that the model is free, so the system is cheap.
The seductive logic, and why it misleads
The build case usually rests on a chain of reasoning that sounds airtight: foundation models are accessible by API, our team can write code, a leasing conversation is not rocket science, and we would own it outright with no recurring vendor fee.
Every link is true in isolation. The problem is that a production AI agent that talks to your prospects and residents is not a model with a prompt. It is a system, and the system is where the cost lives. The model is the easy 10 percent. The hard 90 percent is everything around it: integrations, reliability, compliance, telephony, and the relentless maintenance of all of it. Underestimating that 90 percent is the single most common reason build projects run over and underdeliver.
The hidden costs of building
Integration is most of the work
An AI leasing agent has to do things, and doing things means connecting to systems. Your calendar, your property management software, your phone provider, your email, your SMS gateway, your listing-site inquiries. Each integration is its own project, with its own quirks, auth flows, and edge cases. Then each one needs ongoing maintenance as those external systems change their APIs underneath you. This integration layer typically dwarfs the AI work itself, and it never stops needing attention.
Telephony is harder than it looks
Answering real phone calls with natural, low-latency conversation is a specialized engineering domain. Streaming audio, voice activity detection, interruption handling, and keeping latency low enough that the conversation feels human are genuinely difficult problems. Teams that have never built voice infrastructure consistently underestimate this, and a robotic, laggy phone agent does more harm than no phone agent at all.
Reliability is a 24/7 obligation
The entire point of an AI agent is that it works at 9 PM on a Sunday. That means production-grade reliability: monitoring, alerting, failover, and an on-call rotation. A leasing agent that goes down on a Friday night is dropping leads in real time, with real vacancy cost. Building to that reliability bar is a serious, ongoing operational commitment, not a one-time engineering sprint.
Compliance must be engineered in
This is the cost most build projects discover too late. An AI agent talking to prospects carries full fair housing obligations. It must reliably avoid any line of questioning touching protected classes, and in jurisdictions with source-of-income protections it must not ask about or react to a prospect's use of a housing voucher. Engineering that level of compliance assurance, then testing and auditing it continuously, is specialized work. A subtle prompt change that quietly introduces a discriminatory question is a legal exposure, not a bug ticket.
Maintenance is forever
Building is not a project with an end date. Foundation models change. Integrations break. Compliance rules evolve. Your prompts need tuning as you learn from real conversations. The team that built it cannot move on, because the thing requires continuous care. The recurring cost you thought you avoided by not paying a vendor reappears as a permanent internal team.
The real cost comparison
Set the two paths side by side honestly.
Buying means a recurring fee, less control over the roadmap, and dependence on a vendor. In exchange you get a system that already handles integrations, telephony, reliability, and compliance, live in days rather than quarters, maintained by a team whose entire job is keeping it working. Castellan, for example, ships all of that as a running product, so your team operates rather than builds.
Building means no recurring vendor fee and full control. In exchange you take on the integration layer, the telephony engineering, the 24/7 reliability burden, the compliance engineering, and permanent maintenance. The true cost is a standing team plus the opportunity cost of pointing your best engineers at infrastructure instead of at whatever actually differentiates your business.
When operators run this comparison fully loaded, the build case usually requires either enormous scale, where the recurring fee across a huge portfolio justifies a dedicated team, or a genuine strategic reason the capability must be proprietary. For most, buying is both cheaper and faster once the hidden costs are counted.
When building actually makes sense
To be fair, there are real cases for build:
- Massive scale, where vendor fees across tens of thousands of units exceed the cost of a strong internal team
- A genuine strategic moat, where owning the capability is core to your competitive position, not just a feature
- Highly unusual requirements that no purpose-built vendor serves and likely never will
- An existing world-class AI and voice engineering team already on staff with capacity to spare
If two or more of these are clearly true, build deserves serious analysis. If you are reaching to justify them, that is a signal the honest answer is buy.
The hybrid reality
In practice, many operators land in the middle. They buy the hard, undifferentiated infrastructure, the AI agents, telephony, integrations, and compliance, and they build the thin layer of genuinely proprietary logic that reflects how their specific business operates. This lets the vendor carry the heavy, generic engineering burden while the operator keeps control of what actually differentiates them.
The bottom line
The build-versus-buy decision should never be made on the surface logic that the model is free. The model is the cheapest part. The expensive parts are the integrations, the telephony, the reliability, the compliance, and the maintenance that never ends, and those are exactly what a purpose-built vendor has already solved.
For a small number of operators with the scale, the strategic need, and the team, building is the right call, made deliberately and with the full cost in view. For everyone else, the math favors buying a system that is live in days and maintained by people whose only job is keeping it working, so your team can spend its energy running properties rather than running an AI infrastructure project.