In September 2026 I wrote a LinkedIn post about a client who came to us for scoping and ended up building the whole product himself with AI. I said he was right. The next week I noticed a post by Jeremy T., a partner at Argo Property Group, a Philadelphia real estate developer.
Argo had replaced its property management system (PMS) in June with software it built in-house, and listed Yardi, AppFolio, Buildium, and TurboTenant among the tools it no longer uses. I left the first of about 30 comments under his post from operators and vendors.
My answer to whether property managers should build their own software draws on Yardi's CEO, the operators in Jeremy's thread, the property managers who answered our questions in October 2026, and our own builds. I run a software company, and building is how we get paid. So this is a vendor's answer with the parts that cost us business left in.
TL;DR: Sometimes building is the cheaper choice, because AI made the reports and portals only your company needs cheap to build. Yardi's CEO says that as a client he'd be vibe coding "a pocket of functionality that is very specific to my company." Don't build alone the parts where a mistake costs money or data (the ledger, financial reports, payments, tenant data, and the core business rules), and decide before launch who owns what you build.
- Operators want to see the portfolio without clicking through it
- Sometimes the honest answer is to build it yourself
- Don't build alone anything where a mistake is expensive
- Who builds the whole system, and why it's rarely about price
- Running it after launch is the cost builders leave out
- Building to sell changes what the software has to do
- Build it, keep it on the platform, or hand it to an engineer
- Where Brocoders fits, and when you don't need us
- FAQ
Operators want to see the portfolio without clicking through it
Operators who ask about building their own software usually want the portfolio's numbers on a single screen, without a tour of the platform to find them. Jeremy wanted "rent collection status, OpEx budget tracking, cash-on-cash return, and tenant retention status," without memorizing "a script of click-throughs that felt like a never-ending wiki site."
The second complaint is the vendor's roadmap. A Communications and Creative Services Manager at a U.S. residential community told me in September 2026 that simple changes to their app "can take 9 to 12 months."
Her vendor turns down requests that don't "fit the greater scope of all of their clients." Boards hit the same gap between what they need and what vendors ship.
Until the software catches up, "the team becomes the integration," as Greyson Jones, an AI systems consultant, put it in the thread. My comment asked the next question: "Who owns the 'what if this breaks' part on your side?"
Sometimes the honest answer is to build it yourself
For the parts of the business only you have, building is often the cheaper choice now, and you may not need a vendor for it.
My September post opened with "A client told me he doesn't need us anymore. I think he's right." The client was Julian van der Wouden of Last Hour Experience, and I meant it.
In September 2026 I had a sales call with the manager from that residential community. I told her that a lot of things can now be done on your own with Claude.
She was ahead of me. Her front desk used to spend "like six hours a week" on reports, so she'd built her own AI bot to produce them. She also said that if the website were "information sharing only, I probably would just use a system and build something myself."
Rob Teel, CEO of Yardi, said in an interview that "if I was a client right now I'd be vibe coding," which means building software by prompting an AI model. He'd start with "a pocket of functionality that is very specific to my company."
Building got cheaper for us too. We generated a ServiceTitan-class field service platform from a single requirements document in about 5.5 days, for $1,609 in AI spend. It has 82 database models, 343 application programming interface (API) endpoints, and roughly 454 automated tests.
The $1,609 covers model calls, with review and deployment on top. A dashboard over your platform is a small fraction of that build.
Don't build alone anything where a mistake is expensive
The test is the cost of a mistake: build what you can fix tonight, and keep anything where an error costs money or tenant data on a platform or with engineers. In my September 2026 post I put it this way: AI where the cost of being wrong is low, engineering where the cost of being wrong is high.
That one test sorts every part of the system, and Yardi's CEO draws the line in the same place: "Buy the platform, build the fringe." Teel wouldn't vibe code "an intercompany multicurrency journal" (the records of money moving between your own companies), "a new financial report," or "every business logic rule in our database." On a broad platform built from scratch, his advice is "don't try it."
David Roberson, Principal at Esquire Property Management Group (ESQPMG), manages 350+ units in Silicon Valley on AppFolio "from Day One" and told us: "Daily record-keeping and reconciliation is paramount to maintaining statutory compliance and peace of mind in our business."
[HEADSHOT: media/headshot-david-roberson.jpg | source: NEEDS HEADSHOT (none sent with his reply; ask him at droberson.esq@gmail.com) | alt: David Roberson, Principal at Esquire Property Management Group]
Steven Rea, Chief Innovation Officer at Northpoint Asset Management, pointed in the thread to "a lot of PII and banking info risk," meaning personally identifiable information (PII) and bank details.
The manager I spoke to in September 2026 drew her line at "so much sensitive data," and added: "I don't know enough about AI to make sure that I'm not doing something wrong."
The books and tenant data stay safe while you build the rest. That's how we work when the core has to stay. C.I.A. Services has managed community associations since 1984 and serves over 150 of them.
We built its owner, board, and employee app as a progressive web app (a website that installs and works like a phone app) on top of the system C.I.A. Services wrote and runs. That system stayed in place, and MyRedDog is live for owners.
[IMAGE 1: media/should-property-managers-build-own-software--cost-of-a-mistake.png | alt: Property software parts sorted by the cost of a mistake, from dashboards and portals to ledger, payments, and tenant data]
Who builds the whole system, and why it's rarely about price
The operators who replace the whole system usually run far more than property management, and price is rarely why they do it.
Argo is a developer. In Jeremy's words, they "raise private capital, acquire, design, build, manage, and sell." He's open that building saved them money, and just as open that "most of the major players aren't that expensive on a per-unit basis. The breakthrough for us was understanding what's actually going on in our portfolio."
The reason he gave in the comments was "not needing the Cadillac version but paying for it anyway," plus the need "to connect our full lifecycle to one data set." So Argo dropped QuickBooks, Procore, and BILL as well, and moved its accounting into its own system with Plaid for bank connections.
That's the accounting Teel says not to vibe code. Argo runs it with an outside partner that manages and monitors the infrastructure, and Jeremy wrote that without that partner "we'd probably be more reluctant."
Rich Blanchard, President of R.H. Blanchard Contract & Design in Boston, runs on Buildium and told us: "We would never think of building our own software."
[HEADSHOT: media/headshot-rich-blanchard.jpg | source: https://storage.googleapis.com/ai-templates.appspot.com/bot/CZOjMdOjFkUMpRaoVRJg/logo/profile_1775560143089_linkedin_headshot.jpg | alt: Rich Blanchard, President of R.H. Blanchard Contract & Design]
Rea added in the thread that a full system needs "a real dev team," at $200,000 to $300,000 a year or more in salaries.
For most operators, the useful move is smaller: adding AI to the platform they already run.
Running it after launch is the cost builders leave out
Whatever you build, the bill that arrives after launch is keeping it correct. That work needs an owner.
Reliability is the problem with the first version, as I told the manager on that September 2026 call. It's hard to see what a change touches in the rest of the system.
Ask Claude for a new analytics view, for example, and it may pull the whole database into the browser to calculate it. That works in the demo and slows the whole application once real users load it.
Teel calls this "a hidden cost maintaining code that a lot of folks don't realize," and says agents "can become stale quickly and they need to be refreshed." In his view, real estate companies don't want "to be in the vibe coding business long term."
Alik Levin, who works in property management, built his own interface with Claude on top of an established platform, and still wrote in the thread: "The data integrity part is never solved IMO."
The builders who make it work have an owner, the way Argo has its infrastructure partner. Decide before launch who reviews changes and who answers when it breaks, a person on your team or a partner. Then check it part by part, the way we'd treat a vibe-coded prototype that passed its demo.
Building to sell changes what the software has to do
If other companies ask to use what you built, you're becoming a software vendor, and the build has to change with you.
Argo's build became Airoe, an AI proptech company where Jeremy is a principal, now in early access. Julien Vidal, a Senior Sales Negotiator at Marsh & Parsons in London, told us he co-founded Blyng because he "could not find any software that would offer agents a Virtual Assistant 24/7."
[HEADSHOT: media/headshot-julien-vidal.jpg | source: https://storage.googleapis.com/ai-templates.appspot.com/bot/FW2aIqSavsg9FUQNgJHu/logo/profile_1784290600436_linkedin_headshot.jpg | alt: Julien Vidal, Senior Sales Negotiator at Marsh & Parsons and co-founder of Blyng]
Luke Ashton wrote in the thread that the tool he built for 150 tenants is "Now live for others" as Bricky Bot.
CondoGenie started the same way, as a tool for the founder's own condo board in 2009, and became GeniePad. Starting in 2018, we replatformed it into a multi-tenant software-as-a-service (SaaS) product: a single system serving many customer companies, with each kept apart. The first release came after 18 months, with 9 years of data migrated while the business stayed live, and active users grew from 1,398 in 2019 to 19,324 in 2025.
The second company that logs in needs its data walled off from the first, its own roles and billing, and an audit trail. We've covered internal tools that become SaaS in more detail.
Build it, keep it on the platform, or hand it to an engineer
In a reply under my September 2026 post, I put it this way: "AI moved the 'who can build' line a long way. The 'what deserves engineering' line barely moved."
Make the build-or-buy call part by part, by what a mistake in that part would cost. You end up with 2 lists: what you can build in weeks, and what you should leave alone.
| Part of the system | What a mistake costs | Who should build it |
|---|---|---|
| Portfolio dashboard and owner reports | A wrong number on screen, fixed the same day | You, with AI |
| Internal workflows and AI agents | A stuck task or a stale answer | You, with someone who refreshes them |
| Owner or resident portal | Tenant data shown to the wrong person | You or a partner, with an engineer checking access |
| Ledger, intercompany journals, financial reports | Wrong books and a compliance problem | Keep it on the platform |
| Payments and bank connections | A double charge or money in the wrong account | The platform or a payments provider |
| Tenant personal and banking data | A breach | Engineers, with a named owner for security |
| Core business rules (fees, late charges, and allocations) | Every number downstream is wrong | The platform, or engineers if you replace it |
The portal row is what we built for C.I.A. Services.
Below about 100 units, I'd keep all of it on the platform and spend the time on the business. That's my rule of thumb, and the villa manager below is the clearest case of it. If outside companies start asking for your tool, plan for the build-to-sell changes before you say yes.
[IMAGE 2: media/should-property-managers-build-own-software--build-keep-or-engineer.png | alt: Property management software parts sorted into build it yourself, keep on the platform, or give to engineers]
Where Brocoders fits, and when you don't need us
We told a villa manager with about 23 villas not to build a custom PMS. Her reply: "I really appreciate your honesty, especially in recommending that I don't rush into building a custom PMS simply because your company has the ability to build one."
That's the job as I see it: we do not pitch a rewrite to sell a rewrite. If you're past 100 units and weighing a build, start with a Software audit. It takes 5 or 10 business days, has a fixed scope, and ends in a written recommendation that is allowed to say don't build.
For HeyPractice, a sales training SaaS, a free audit came back before the quote, and the product was in production 5 months after the audit. The rest of our proptech work is on the industry page.
FAQ
Is it cheaper to build property management software with AI now? It often is for a dashboard or owner reports on top of your platform, since we generated a whole field service platform in about 5.5 days for $1,609 in AI spend. A full system rarely is: an operator in Jeremy's thread puts a real dev team at $200,000 to $300,000 a year in salaries.
What should never be custom in property management software? Keep the ledger, intercompany journals, financial reports, payments, and core business rules on your platform unless engineers will own that code. Yardi's CEO wouldn't vibe code an intercompany journal, a new financial report, or the business rules in his database either.
Can a small property management company build its own software? It can build small tools on top of its platform. Below about 100 units, I'd keep the core on an off-the-shelf platform, which is what we told a villa manager with about 23 villas.
Who maintains in-house property management software after launch? Name that person before launch: someone on your team or an outside partner who knows the code and reviews every change.
What about tenant payment data and personally identifiable information (PII) if we build our own? Keep payments with a payments provider or your platform, and keep PII behind access rules an engineer has checked.
Can we build on top of Yardi or AppFolio instead of replacing it? Yes, and Yardi's CEO recommends it: "Buy the platform, build the fringe." Build on the data your platform lets you read or export.
When does it make sense to turn our in-house software into a product? It makes sense when outside companies ask to use it and you're ready to run a software business. CondoGenie's first multi-tenant release took 18 months.