You should fire a proptech vendor and build your own only when a narrow set of conditions all hold at once — the tool blocks a workflow that is central to how you win, the vendor cannot or will not fix it, per-seat cost has passed the price of owning the capability, and you have someone who can keep a build alive. Frustration alone is not a trigger, and “build your own” is the rarest correct exit. Most firms that reach this question have two cheaper moves in front of the build — switch vendors, or drop to a thin AI workflow for the one job the tool failed at — and skip straight to the most expensive one. This is the honest version of the decision: the signals that actually justify leaving, the three exits ranked by what they cost a small shop, and the maintenance bill a build quietly transfers onto a team with no engineer.
What firing a proptech vendor actually means
Firing a proptech vendor is not one decision. It is two, and most people collapse them into one and get the second one wrong.
The first decision is whether to leave the tool. The second is what replaces it. When a principal says “we should just build our own,” they have usually made the first decision on emotion — a price increase, a support ticket that went nowhere, a feature the roadmap never shipped — and then jumped to the most dramatic answer to the second. The build is the answer that feels like taking control. It is rarely the answer that math supports.
Every proptech subscription your firm runs — a property management platform like Yardi Breeze or AppFolio, a deal-pipeline tool like Dealpath, a listing and marketing tool like Buildout, a CRM like Apto or HubSpot, a lease-intelligence tool like Prophia or Leasecake — is renting you a bundle: the software, the ongoing maintenance of that software, the data model, the integrations, and the compliance posture around your data. When you fire the vendor, you stop renting all of it. Building your own means you now own all of it. That distinction is the whole article, because the part firms notice is the software and the part that breaks them is everything else in the bundle.
The full framework for when off-the-shelf tools are genuinely enough — and when they stop being enough — runs through our buy-vs-build playbook for small CRE firms. This piece is the narrower, harder case: you already bought, and now you are deciding whether to walk.
The five signals that justify leaving
A build becomes defensible only when the reasons to leave are structural, not situational. Here are the five signals that hold up. You want most of them present at once, not one in isolation.
1. The tool blocks a workflow that is central to how you win. Not a nuisance — a workflow that is part of your edge. If your firm competes on a proprietary underwriting model, a specific deal-screening process, or a portfolio reporting format your investors expect, and the platform forces you into its shape instead of yours, that is a structural mismatch. A tool that is merely clunky is not this. A tool that caps the thing you are actually better at is.
2. The vendor cannot or will not fix it. You have asked, more than once, and the answer is a roadmap with no date or a flat no. A small firm has no sway over a large platform’s priorities, so a feature that matters only to shops like yours will not get built. Confirm this is a real wall, not a support ticket you filed once.
3. Per-seat cost has passed the crossover point. Proptech pricing scales with seats or units. As your team grows, the annual subscription can climb past what it would cost to own the capability outright. When you can honestly model the fully loaded cost of a build — including the years of upkeep after it ships — against several years of rising subscriptions, and the build wins, that is a real signal. The cost side of that model is laid out in our guide to how much a small CRE firm should budget for AI each year.
4. Your data is genuinely trapped — or the platform’s generic AI cannot touch your process. Two variants of the same problem. Either the tool holds your data in a form you cannot get out cleanly, so it dictates your future by default, or its built-in AI features are one-size-fits-all and cannot be pointed at the specific process that differentiates you. Verify the first before you claim it: many platforms do offer usable export, and if yours does, the lock-in argument weakens.
5. You have structurally outgrown the tool. It was built for a firm at a stage you have passed. A platform sized for a two-person shop cannot carry a fifteen-person operation, and no amount of configuration closes that gap. This is the cleanest signal, and the one least likely to reverse.
One signal is a reason to complain to your account manager. Three or more, present together, is a reason to run the decision test below.
The three exits, ranked by cost
Here is the reframe that saves most firms from an expensive mistake. “Fire the vendor” has three exits, not one, and building is the last resort, not the default.
Exit one — switch to a better-fit vendor. The cheapest exit. If your complaint is a missing feature or bad pricing, another platform in the same category may solve it for the cost of a migration, with the maintenance still carried by a vendor. Firms skip this because switching feels like admitting the first purchase was a mistake, but it is almost always cheaper than owning software.
Exit two — keep the system of record, add a thin AI workflow for the one job that failed. Often you do not need to leave the platform at all. If the tool is a fine system of record but weak at one task — drafting listing copy, summarizing a lease, reconciling a rent roll, triaging inbox-to-CRM — a thin workflow using ChatGPT, Claude, or Microsoft Copilot with saved prompts can do that one job alongside the platform you keep. No migration, no build, no engineer. This is the exit that resolves most “I’m frustrated with the AI in my tool” complaints, and the sequencing question behind it — fix people first or software first — is the subject of our comparison of workshop-first versus software-first AI spending.
Exit three — build your own. The most expensive exit and the only one that transfers the entire maintenance bundle to you. Defensible only when the five signals point hard at a structural problem no other vendor solves and no thin workflow patches — when what you need to own is your process itself. For a scoped custom automation in the current market, budget roughly $25,000 to $150,000 depending on complexity, and then keep budgeting, because the build cost is the down payment, not the price.
Rank your situation against these in order. If exit one or two solves it, you are done, and you have saved a year and a six-figure line item.
The maintenance you inherit the day you fire the vendor
This is the fact that vendor marketing and custom-development sales pitches both leave out, from opposite motives.
The subscription you resent was paying for invisible work. The vendor was updating the software as document formats and data sources changed, patching security holes, maintaining the integrations to the other tools in your stack, evolving the data model, and holding the compliance posture around confidential tenant and deal data. None of that shows up on the invoice as a line item, so it is easy to believe you are only paying for the software you see.
Fire the vendor to build your own and you inherit every one of those jobs. A custom system does not maintain itself. Someone has to keep the extraction accurate as the documents you feed it change, patch the dependencies, fix the integration the day a connected tool updates its interface, and answer for the security of the data inside it. In a 4-to-20-person firm with no IT department, that someone does not exist, which means the work either does not happen or lands on a broker who did not sign up for it.
The small-firm advantage is speed and low overhead, and a standing maintenance obligation you cannot staff erases both — the same discipline that runs through the manifesto on how small CRE firms out-operate larger competitors. Owning software you cannot maintain is not control. It is a liability that surfaces at the worst possible moment, usually mid-deal.
The switching cost small firms underweight
Even when a build is the right call, the transition costs more than the build quote. Three costs get underestimated every time.
First, data migration. Getting years of records out of one platform and into a new system, cleanly and completely, is rarely a button. Expect to reconcile, de-duplicate, and validate — and to discover that some of what you thought you owned is harder to export than the sales demo implied.
Second, retraining. Your team is fluent in the old tool. A new system, custom or otherwise, resets that fluency to zero, and the productivity dip during the changeover is real. This is why building AI fluency in your people is a prerequisite to any tooling change, not an afterthought — the case for buying AI capability without an IT department is made in our ten rules for buying AI without an IT department.
Third, dual-running. You cannot flip a system of record overnight. For a period you run both the old and new tools in parallel, paying for the subscription you are trying to escape while the replacement proves itself. Budget for that overlap; firms that assume a clean cutover get surprised by a quarter of double cost.
A five-question decision test
Run your situation through these in order. If the answers do not point hard toward a structural problem only ownership solves, you are on exit one or two, not exit three.
- Is the problem structural or situational? A workflow the tool caps on your core edge is structural. A price bump or a clunky screen is situational. Situational problems have cheaper fixes.
- Has another vendor already solved it? If a competing platform fixes your complaint, switch — do not build. Only build when no vendor in the category fits.
- Can a thin AI workflow patch the one job that failed? If the tool is fine as a system of record and weak at one task, add a workflow beside it and keep the platform.
- Who maintains the build between crises? Name the person. If you cannot, you cannot own software, and the build is off the table regardless of the other answers.
- Does the transition math still win after migration, retraining, and dual-running? Add those to the build quote before you compare. If it still beats several years of subscriptions, the build is real. If it only wins on the sticker price, it does not.
The four options, side by side
| Dimension | Stay and adapt | Switch vendors | Thin AI workflow beside the tool | Build your own |
|---|---|---|---|---|
| Best for | Situational gripes, no structural block | A missing feature another platform has | One weak task on an otherwise fine system of record | A structural block on your core edge, no vendor fits |
| Upfront cost | None | Migration only | Low — a subscription you likely have | High — a full build |
| Who maintains it | The vendor | The new vendor | You, per task | You, forever |
| Data ownership | Vendor’s model | New vendor’s model | You keep outputs | Full — you own the layer |
| Risk | Keeps a poor fit | Migration effort | Minimal | Inheriting the whole maintenance bundle |
| How often it is the right answer | Common | Common | Common | Rare |
Read the last row. Three of the four options solve most cases, and all three keep the maintenance burden off a team that cannot carry it. The build column is correct only when the earlier columns genuinely fail — and for a small firm, that is the exception, not the rule.
How to pressure-test the decision before you commit
Before you sign a build contract or a termination notice, prove the decision on something small. The test is the same shape whichever exit you are weighing.
Take the single workflow that drove the whole question — the one the current tool blocks or does badly. Rebuild only that, at the smallest honest scale: a thin workflow with saved prompts, a trial of the competing vendor, or a tightly scoped pilot of a custom build covering that one process and nothing else. Run it against real data from your own firm, including the messy records, not a clean demo set. Then ask two questions: did it actually solve the problem, and who kept it working during the test? If the pilot only worked because a vendor or a consultant was holding it up, that tells you exactly who will need to hold up the full version — and whether that person is on your payroll.
That second reading is the one firms skip, and it is the one that decides the case. A build that solves the workflow but has no owner between deals is not a solution; it is a future emergency. Confirm both before you commit a dollar or send the termination email.
Frequently asked questions
When should a small CRE firm fire a proptech vendor and build its own tool?
Only when a narrow set of conditions hold together: the tool blocks a workflow central to how your firm competes, the vendor cannot or will not fix it, per-seat cost has passed the fully loaded price of owning the capability, no competing vendor fits, and you have someone who can maintain a custom system. If any of those is missing — especially the maintainer — a build is the wrong move. Most firms that reach this question are better served by switching vendors or adding a thin AI workflow beside the tool they keep.
Is building your own proptech cheaper than paying a subscription?
Rarely, once you count the full cost. A scoped custom automation runs roughly $25,000 to $150,000 in the current market, but the build price is a down payment — you also inherit the maintenance the vendor was doing invisibly, plus data migration, retraining, and a dual-running period. Building beats subscribing only when per-seat costs have climbed past the fully loaded, multi-year cost of ownership and you have staff to maintain the result. For most small firms, a subscription is the cheaper way to keep the maintenance burden off a team that cannot carry it.
What are the signs it is time to leave a proptech platform?
The structural ones: the tool caps a workflow that is part of your competitive edge and the vendor will not change it; you have outgrown the stage the platform was built for; per-seat pricing has passed the point where owning the capability is cheaper; or your data is genuinely trapped in a form you cannot export cleanly. A price increase, a clunky interface, or a single bad support experience are situational, not structural, and they usually have cheaper fixes than leaving.
Should I switch vendors or build my own?
Switch first, almost always. Switching to a better-fit platform solves a missing feature or bad pricing for the cost of a migration, and the maintenance stays with the vendor. Build only when no vendor in the category fits — when what you need to own is your own process, not a feature another product already has. Building because you are annoyed with one vendor, when a competitor would solve the problem, trades a fixable complaint for a permanent maintenance obligation.
Can I keep my current tool and just add AI to it?
Often, yes, and it is the exit most firms overlook. If your platform is a solid system of record but weak at one task — drafting listing copy, summarizing a lease, reconciling a rent roll — a thin workflow using ChatGPT, Claude, or Microsoft Copilot with saved prompts can handle that one job alongside the tool you keep. No migration, no build, no engineer. This resolves most “the AI in my tool is disappointing” complaints without leaving the platform at all.
What maintenance do you inherit when you build your own proptech?
All of it. The vendor was patching the software, updating it as document formats and data sources changed, maintaining integrations to the rest of your stack, evolving the data model, and holding the security and compliance posture around your data. A custom build transfers every one of those jobs to you. In a firm with no IT department, that work either goes undone or lands on a broker, which is why “who maintains it” is the question that ends most build cases before cost even enters the conversation.
How do I know if my data is really trapped in a vendor’s platform?
Test the export before you assume it. Many platforms offer usable, structured export of your records; some do not, and the difference decides how much weight the lock-in argument really carries. Ask for a full export in a usable format and check whether the data comes out clean and complete, or whether reconstructing it would take significant work. If export is genuinely poor, that strengthens the case to leave; if it is clean, the lock-in complaint is weaker than it felt.
How should I test the decision before committing?
Rebuild only the workflow that drove the question, at the smallest scale, against your own real data — a thin workflow, a competitor’s trial, or a tightly scoped build pilot covering that one process. Then check two things: did it solve the problem, and who kept it running during the test. If it only worked because a vendor or consultant was holding it up, that is who will hold up the full version too — and whether that person is on your staff decides the whole question. The test costs a few days and prevents a six-figure mistake.
Does firing a proptech vendor require an IT department?
To build a replacement, effectively yes — or a standing relationship with someone who can maintain it. That is precisely why building is the rarest correct exit for a 4-to-20-person firm. The other exits — switching vendors or adding a thin AI workflow — do not require an IT department, because a vendor still carries the maintenance. Leave a proptech vendor for a custom build without a maintainer in place and you have not gained control; you have created an unstaffed liability.
Where to start
The first question is not which build shop to hire or which termination clause applies. It is whether your problem is structural enough to justify leaving at all — and, if it is, whether switching vendors or adding a thin workflow solves it before you commit to owning software you have to maintain. A free AI-readiness assessment produces that read: a short working session that maps which tools you run, where each one genuinely fails you, and whether your team is fluent enough that any custom path is safe yet. It returns an honest recommendation — stay and adapt, switch, add a workflow, or build — before you spend a dollar or send a notice. Book a free AI-readiness assessment before you fire anyone.
Arthur Wandzel
