Build vs buy is the question of whether to subscribe to an existing software product or commission software built for your firm alone — and for a 4-to-20-person commercial real estate firm, it is usually the wrong question. It arrives from enterprise IT, where a company either licenses a platform or has an engineering team build one. A small CRE firm has neither of those extremes as its real choice. Ask “build or buy” and you skip past the two options that fit a small shop best, and you turn a routine decision into a false either-or between a monthly subscription and a platform you have no one to run. The better question, for any workflow in front of you, is simpler: what does this specific task actually need?
What build vs buy actually means
Build vs buy is a decision about who owns the software that runs a workflow. Buy means you subscribe to a finished product — CoStar for market data, Buildout for listing marketing, Yardi or AppFolio for property management, Dealpath for deal pipeline. The vendor owns it, shares it with thousands of firms, and decides what it does next. Build means software made for your firm’s specific requirements, owned by you, and changed only when you pay to change it.
Stated that cleanly, the tradeoff sounds obvious: buy is cheap and generic, build is expensive and exact. That framing is accurate for a large company choosing between a licensed enterprise platform and its own engineering team. It is where the phrase comes from, and it is why almost every article you will find on the subject reads like it was written for a chief information officer.
You are not that reader. You run a lean CRE firm with no IT department, deal data that cannot leak, and a set of workflows that live in Excel, Outlook, and PDFs. The enterprise version of the build-vs-buy question does not describe the decision you actually face — and taking it at face value leads to the two most expensive mistakes small firms make with technology.
Why the binary misleads a small firm
The binary misleads because it deletes the middle, and the middle is where small firms belong. Between “subscribe to a product as-is” and “commission a platform from scratch” sit two options that fit a small shop far more often than either pole.
The first is configuring a tool you already pay for. Serious CRE software is rarely rigid — it has custom fields, templates, workflow rules, and integrations you can shape to your process without writing a line of code. A firm that says “our CRM doesn’t do what we need” has usually not exhausted what the CRM already does through its own settings.
The second is a thin automation layer: a lightweight workflow built on tools you already have — ChatGPT, Claude, or Microsoft Copilot — wired to your existing files and inboxes to do one narrow job no product handles. It is neither a subscription nor a platform. It is the cheapest way to close the gap between a good tool and your exact process, and the option the build-vs-buy binary cannot see.
Miss the middle and one of two things happens. You force a full custom build for a problem a configured tool would have solved, and overpay by an order of magnitude. Or you conclude “nothing on the market fits” and keep doing the work by hand forever, when a few days of automation would have closed the gap. The full menu — buy as-is, configure, thin layer, or build — is laid out in our guide to custom software versus off-the-shelf for CRE principals. The point here is narrower: once you can see four options instead of two, the decision stops being a coin flip and becomes a diagnosis.
The three biases that distort the decision
Before the diagnosis, name the distortions. The build-vs-buy call at a small firm is rarely made on cold logic. Three predictable biases push it off course, and each has a counter-move.
The “we’re special” instinct. Every firm believes its way of doing a common task is unique. Usually it is not — it is simply familiar, and a configured off-the-shelf tool would handle it fine. Building custom software to preserve a habit is the single most common way small firms waste money on technology. The counter-move: assume the task is standard until you can name the specific thing no product does. If you cannot name it in a sentence, it is standard.
The sunk-cost trap. A proptech subscription nobody uses stays on the books because it is “already paid for.” The money is gone whether you keep the seat or not — the only live question is whether it earns its keep going forward. The counter-move: judge every tool on next year’s value, not last year’s invoice. If the team would not re-buy it today, it is a candidate to cut, not a reason to build around.
Vendor-pitch capture. Whoever is in the room defines the options. Talk to a proptech vendor and the answer is buy their product; talk to a dev shop and the answer is build something custom. Both are honest and both are incomplete. The counter-move: decide what the workflow needs before you take the meeting, so the pitch has to fit your question rather than the reverse.
The five questions that answer it
The real question is not “build or buy.” It is “what does this specific workflow need?” — and you can answer it yourself, for any workflow, by running five checks in order. Stop at the first one that gives you a clear answer.
-
Is this task standard across the industry? Storing comps, sending a listing to a portal, tracking a lease’s key dates, running a property ledger — if thousands of firms need the identical thing, a product already does it, and better than anything you would commission. If yes, buy off-the-shelf and stop here.
-
Does a tool we already own do it, if configured? Before adding anything new, check whether the gap closes with fields, templates, rules, or an integration inside a platform you already pay for. Configuring a product that is eighty percent right is far cheaper than replacing it. If yes, configure and stop here.
-
Is it one narrow job, or many? If a real, repetitive task falls in the gap between products — narrow enough to describe in a sentence, painful enough to matter — a thin automation layer on your existing tools is usually the answer. If the “one task” is actually five tasks in a trench coat, it is not a thin layer; treat it as a build and keep going.
-
Who owns this on Monday when it breaks? Whatever you choose, someone at your firm has to run it — and that someone is not a systems administrator, it is you, a broker, or an ops lead with a full plate. If you cannot name the person or the standing outside relationship who owns a custom build when a document format changes, the answer is not a build. Push back up to buy or configure.
-
Does this workflow actually win us business? A full custom build earns its place only when the process is genuinely how you out-operate bigger firms — the specific way you screen deals, underwrite, or manage a niche asset class that a competitor cannot copy off a subscription. If the workflow is a commodity every firm runs, buy it and spend your build budget where being different matters.
The pattern across the five is the same: choose the simplest option that actually solves the problem, because every step toward “build” costs more to commission and more to keep alive. Start at the top and move down only when forced.
Working an example: a lease-renewal tracker
Take a concrete case. Your firm keeps missing lease renewal and option dates buried in a stack of PDFs, and someone floats “we should build a system for this.” Run the five checks.
Is tracking lease dates standard? Yes — most property management and lease administration platforms do it. Does a tool you already own handle it? If you run AppFolio, Yardi, or Buildium, key-date tracking is very likely already in there, unused. For most firms, the diagnosis ends at check two: the capability is already paid for and just needs to be turned on and populated.
Now change the facts. Suppose the dates live in incoming lease PDFs that no one has time to key into the system, and that data-entry gap is the real problem. Check three applies: extracting a handful of fields off each new lease into a clean summary is one narrow, describable job that no subscription does exactly. That is a thin automation layer — a few days of work on tools you already have, not a platform. Check four still governs it: keep it simple enough that one non-technical person can run it. Nowhere in this example is a full custom build the right answer, and that is the typical result.
What each answer costs, in real ranges
Cost is where generic guides scare small firms off entirely, quoting six- and seven-figure custom-build numbers pulled from enterprise projects. At CRE-firm scale the ranges are far more human, and they track the five-question ladder directly.
Buying off-the-shelf is an ordinary subscription — tens to low hundreds of dollars per user per month, more for premium data services. Configuring a tool you already pay for is mostly your own time. A focused fluency workshop that gets your team using off-the-shelf AI well runs roughly $2,000 to $15,000 in the current market, and it is often the cheapest fix of all, because a trained team handles by hand what looked like it needed software. A thin automation layer or a right-sized custom build covering one workflow runs roughly $25,000 to $150,000 depending on complexity, with a sensible first project aimed at the low end.
The ranges give you direction, not a quote. Move up the ladder toward buy and cost drops toward a subscription; move down toward build and it climbs toward a project. Match the spend to how much the workflow actually differentiates you — a discipline covered end to end in our buy-versus-build playbook for small CRE firms.
How to make the call this quarter
You do not need a consultant or a weighted scorecard to make this decision. You need one painful workflow and an afternoon. Write the workflow at the top of a page, run the five questions down it, and stop at the first clear answer. Most workflows resolve at check one or two — buy or configure — and never should have been framed as a build in the first place.
For the handful that reach checks three through five, the next move is to understand what a real project looks like before you commission one. A thin automation layer still has a shape — discovery, a scoped build, a pilot, and a handoff — and knowing that shape keeps a small job from quietly turning into a large one, which is exactly what how AI automation projects actually work, from discovery to deployment walks through. If you are still getting oriented to what is even for sale, a tour of the commercial real estate technology landscape is the place to start.
The larger point is the one that lets a lean firm out-operate institutional giants: do less, but do it exactly. Buy the commodities, configure what you already own, automate the narrow gaps, and reserve a real build for the rare workflow that is genuinely your edge. That discipline — spending only where being different wins deals — is the through-line of our manifesto on how 4-to-20-person shops out-operate the giants.
Frequently asked questions
What does “build vs buy” mean for a small real estate firm?
Build vs buy is the decision of whether to subscribe to a finished software product or commission software built for your firm alone. For a small CRE firm the phrase is misleading, because it hides the two options that usually fit best: configuring a tool you already pay for, and adding a thin automation layer on top of your existing tools for one narrow task. The better question for any workflow is not “build or buy” but “what does this specific task actually need” — which resolves to the simplest of four options, not a binary.
Should a small CRE firm ever build custom software?
Rarely, and only under a specific test: the workflow is central to how you win, no off-the-shelf tool fits it, configuring a tool you own cannot close the gap, and you can name the person who owns the software when it breaks. For most small firms an off-the-shelf product, a configuration, or a lightweight automation solves the problem for a fraction of the cost. A full custom build is the exception you can count on one hand, not the answer to a routine frustration.
How do I decide between buying proptech and building my own?
Run five checks in order and stop at the first clear answer: Is the task standard across the industry? Does a tool you already own do it if configured? Is it one narrow job or many? Who owns it when it breaks? Does the workflow actually win you business? Each check pushes you toward the simplest option that works — buy, configure, a thin automation layer, or, only when all five point that way, a custom build. Most workflows resolve at the first two checks.
Isn’t custom software always too expensive for a small firm?
Not at CRE-firm scale. Generic guides quote six- and seven-figure numbers from enterprise projects, but a thin automation layer or a right-sized custom build covering one workflow runs roughly $25,000 to $150,000 in the current market, with a first project aimed at the low end. Off-the-shelf tools remain ordinary subscriptions, and a fluency workshop that gets your team using existing AI well runs roughly $2,000 to $15,000. The cost tracks the option you choose, so the discipline is to buy or configure wherever that genuinely solves the problem.
What is a thin automation layer, and how is it different from building?
A thin automation layer is a lightweight workflow built on tools you already have — ChatGPT, Claude, or Microsoft Copilot — wired to your existing files and inboxes to do one specific job an off-the-shelf product does not, such as pulling key fields off every incoming lease. It is not a platform you build from scratch and not a product you subscribe to. It costs a fraction of a full custom build, and one non-technical person can keep it running as long as it stays narrow. The risk is scope: a thin layer that tries to do five jobs becomes an accidental build.
We have no IT department. Does that change the build-vs-buy answer?
Yes, decisively. Whatever you choose, someone at your firm runs it — and with no systems administrator, a bespoke platform with no one to maintain it becomes an orphan the first time it breaks. “Who owns this on Monday” is often the check that settles the decision. If you cannot name the person or standing outside relationship who owns a custom build, the honest answer is an off-the-shelf tool the vendor maintains, or a thin automation layer simple enough for one non-technical person to run.
How does confidential deal data affect the decision?
It raises the bar on anything custom. Off-the-shelf vendors publish security and data-handling documentation you can review before trusting them with LOIs, financials, and deal terms. A thin automation layer inherits the security controls of the platform beneath it, which you should verify before sending sensitive files through it. A full custom build shifts data-protection responsibility onto you and whoever built it — a real cost that generic build-vs-buy comparisons leave out, and another reason to favor the simplest option that works.
Why do vendors and developers give me opposite answers?
Because whoever is in the room defines the options. A proptech vendor will honestly conclude you should buy their product; a development shop will honestly conclude you should build something custom. Both are giving you a real answer to the wrong question. The fix is to decide what the workflow actually needs — using the five checks — before you take either meeting, so the pitch has to fit your question rather than setting it.
What is the first thing I should do?
Pick your single most painful workflow, write it at the top of a page, and run the five questions down it: standard task, configurable existing tool, one job or many, who owns it, does it win business. Stop at the first clear answer. Most workflows resolve at “buy” or “configure” and never needed to be framed as a build. For the few that reach a thin automation layer or a build, understand what a real project looks like before commissioning one.
Where to start
The first move is not to pick a vendor or a developer — it is to place your most painful workflow against the five questions and see where it lands. A free AI-readiness assessment does exactly that with you: it identifies the workflow, tests whether an off-the-shelf tool or a quick configuration already solves it, and only points toward a thin automation layer or a build when nothing simpler will do. Book a free AI-readiness assessment before you buy or build anything.
Arthur Wandzel
