The build vs. buy debate is the wrong question. The real question is which layer you own, the layer you decide to build at.

A property manager's biggest owner calls on a Tuesday morning. His disbursement came in $1,900 light and he wants to know why.

The answer exists. The ledger is in the PMS: a plumbing invoice and a reserve top-up. The approval is in a phone call nobody can pull the recording for. The reasoning behind the approval is in a ChatGPT conversation the maintenance coordinator had on her personal account two weeks ago, where she pasted the bids and worked out why the $1,400 repair beat the $600 patch. She's on PTO.

The PM spends forty minutes reconstructing a decision his own company already made. The owner spends those forty minutes wondering if anyone's watching his money.

Here's the thing. Those aren't three problems. They're one problem. This company owns the wrong layer of their technology stack.

Buildium published a piece this month on vibe coding in property management. Their argument: AI-generated tools are fine for gap-filling, but anything load-bearing belongs in purpose-built software. Todd at PMAssist ran a debate between the AI-first camp, which says rebuild your processes from scratch around AI, and my position, which he summarized fairly: most PMs are too deep in the daily weeds to burn their operation down and redesign it.

Buildium's risk assessment is correct. A vibe-coded tool works great until it becomes load-bearing, and then it breaks at the worst possible time, and there's no support line to call. They're right about that.

Their conclusion only follows if your PMS is your operating system. It isn't. It's your accounting system. It was built to keep your books clean and your trust accounts compliant, and it should keep doing exactly that.

The AI-first camp is right too, and they've earned the position. These aren't outside consultants theorizing. They're real property management owners who vibe-code their own operations and have made genuine changes to their businesses doing it. It works for them.

But notice why it works for them. They've decided to be the architect. That's a real business model: the owner is the builder, the system is their craft, and the operation is shaped around their hands staying on the keyboard. The other model is the delegating owner, who builds a team and a system that runs without them in it. Neither is wrong. But you have to pick one on purpose, because everything downstream depends on it.

I experienced what happens when you don't pick in a previous life, in advanced manufacturing. Every production line ran on ladder logic, and all of it lived in the head of one exhausted old engineer. Brilliant guy. Also a single point of failure. The company couldn't replace him, couldn't promote him, couldn't scale past him. His own life was whittled down to babysitting this system himself. We’re talking a Fortune 100 manufacturing company sitting on his shoulders. He wasn't an asset anymore. He was a bottleneck with a badge.

Bespoke systems always route through somebody. If you're the architect, that somebody is you, and you've chosen it. If you're the delegating owner and your operation runs on custom code, you've just hired your own grouchy engineer. The real decision is what level you should be bespoke at, and how much of that responsibility you actually want to carry in-house.

Both camps are answering the wrong question. It was never build vs. buy. It's not even architect vs. delegator. The question is which layer do you own.

Own the config. Rent the rails. Get that right and the architect keeps building where it counts, the delegator sleeps at night, and neither of you ends up with a bottleneck holding the keys. Let me show you what it looks like at four layers.

Building your own CRM from scratch is the vibe-coding trap at full scale. You'd own the database, the permissions model, the mobile apps, the uptime, and every 2am failure. We build software for a living. We still don't build our own CRM. That should tell you something.

But living entirely inside your PMS means someone else owns your workflows, and you rent them back one feature release at a time.

The middle path is a configurable platform. We use monday.com. Monday owns the infrastructure: servers, security, mobile apps, permissions, uptime. You own the configuration: your boards, your automations, your statuses, the actual shape of how your company runs. That's not code. Nothing breaks when the person who set it up leaves. There's a support team and an uptime SLA behind all of it.

And when off-the-shelf hits a wall, you don't abandon the platform. You extend it. When our clients needed flat-rate e-signing, we didn't move them to a standalone tool with its own login and its own dashboard. We built it inside monday. Same board, same workspace, same team. The platform is rented. The workflow is yours.

Same rule, telephony layer. You have three doors.

Door one: build on Twilio. I can tell you exactly what's behind this door, because we run Twilio subaccounts inside our own communications product. This isn't fear of the tool. It's knowing what you sign up for: A2P 10DLC registration, carrier compliance filings, deliverability monitoring, and outages that are yours to debug. Twilio is phenomenal infrastructure. It is also a part-time job. If you build your phone system on raw Twilio, you now run a small phone company that happens to manage property.

Door two: a legacy suite. RingCentral works. It's been working since before the iPhone. But it's a platform built and priced for a world before AI-native calling, and the AI features arriving now are bolted onto architecture that predates them.

Door three: a modern managed platform. This is why we're moving to Aircall. Per-license pricing that makes sense at team scale, 200+ native integrations, and AI built into the calling layer itself: call summaries, transcription, coaching, and a voice agent that lives on the same system your team answers on. They bought an AI voice company this spring specifically to deepen that layer. They're investing where this is going, not retrofitting where it's been.

Aircall owns the carriers, the compliance, the uptime. You own the routing logic, the workflows, the numbers. Config yours, rails theirs.

This market is splitting into two bad defaults.

On one side, black-box vertical answering services. They handle your calls, but the behavior is theirs. You can't see the prompt, can't tune the escalation rules, can't teach it that a dripping faucet waits until morning but "water is coming through the ceiling" pages someone now.

On the other side, raw builder platforms. Total control, and total ownership of every failure mode: the latency, the interruptions, the model updates that silently change behavior on a Thursday.

Our stance: the prompt is yours, the platform is theirs.

The prompting is not a technical detail. It IS your operations knowledge. How your company handles a 9pm maintenance call. What counts as an emergency. When a human takes over. That changes as your business changes, so it has to be configurable by you, in plain language, without a developer. But speech models, turn-taking, telephony, and handoff mechanics? A vendor's problem. You will never out-engineer a funded platform team on latency, and you shouldn't try.

Then there's the question I get most: "What about Claude? I want to ask questions about my own data and get real answers."

Here's what that looks like at most PM companies right now. The ops manager has ChatGPT. The BDM has Claude. The maintenance coordinator has whatever was free. Everyone pastes company data into personal accounts, has the same conversation five separate times, gets five different answers, and none of it is visible to anyone else. When the person leaves, the reasoning leaves with them. That Tuesday-morning owner call at the top of this post? That's the silo tax, collected.

AI belongs in the workspace, not in personal chat tabs. When someone works out why the $1,400 repair beat the $600 patch, that reasoning should live on the work order, next to the bids, where the PM finds it in ten seconds while the owner is still on the phone. One shared context. One place the whole team refers to.

And notice this only works because of Layer 1. An AI can only reason over your operation if your operation is structured somewhere it can see. A personal ChatGPT account can't see your boards. Workspace AI can. Every layer you own feeds the next one.

Old model: pick a camp. Rebuild everything with AI and own code nobody maintains, or wait for your vendors to ship AI and rent your own workflows back at a markup.

New model: own the configuration at every layer. Your workflows on a rented platform. Your routing on rented rails. Your prompts on a rented voice engine. Your AI in a shared workspace, reasoning over structured data you control.

Todd's right that AI-first wins eventually. AI-ready isn't the timid version of that. It's the sequenced version. The companies that own their config layer today are the ones who get to AI-first without betting the business on a coin flip.

If explaining a short disbursement currently takes four logins and someone's personal chat history, book a demo and we'll show you what it looks like when the answer lives in one place.

The stack in this post:

Some of these are partner links. We recommend them because they're what we run and deploy for clients, and the commissions don't change what we'd tell you to buy.