At some point every growing property company faces a version of this conversation. The systems are not doing what the business needs. Someone proposes building something internal, tailored exactly to how you operate. Someone else says buy, because building software is not what you do. And the CEO, sensing a technical argument, sends it downstairs to be resolved by people who understand technology.

That instinct is understandable and it is wrong, and it is wrong in a way that costs real money. Forrester found that 67 percent of software projects fail because the build-versus-buy choice itself was wrong, not because the execution was poor. Read that again. The most common cause of software failure is not bad engineering. It is a good team building or buying the wrong thing, having answered a strategic question with a technical process.

Because underneath the vendor comparisons and the cost models, this question is not really about software. It is about what your company is actually good at, what part of your operation genuinely differentiates you from the firm down the street, and where you want your best people spending the next three years. Those are not IT decisions. They are the CEO's, and delegating them means the answer gets made by default rather than on purpose.

The case for building, made seriously

It is worth stating the case for building properly, because it is stronger than software vendors usually admit and most CEOs hear only a caricature of it.

McKinsey's research found that high-performing companies develop more than 90 percent of their genuinely differentiating applications internally, and that firms building strategic digital assets aligned with their core business achieve materially higher margins. That is not a fringe finding. It says something important: if a capability is truly the thing that makes you better than your competitors, buying the same off-the-shelf product they buy hands that advantage away. You cannot differentiate on software that everyone else can license on Tuesday.

So when a property company builds something because its way of underwriting a deal, or its particular approach to resident retention, or its specific method of managing a complicated asset class is genuinely distinctive, and no product on the market can express it without gutting what makes it work, building can be exactly right. Standardizing to fit commercial software would mean sacrificing the edge, and preserving that edge is worth real money and real complexity.

That is the honest case, and a CEO should take it seriously rather than dismiss it as engineers wanting to build things.

The question that actually decides it

The useful lens here is decades old and still unbeaten. Geoffrey Moore called it core versus context. Core activities are the ones that directly create your competitive differentiation, the things a customer or an investor would point to and say, that is why this company wins. Context is everything else: necessary, sometimes critical, but not what sets you apart. Payroll is context. Email is context. So, for almost every property company, is the general ledger.

The question is therefore not "can we build this?" A capable team can build almost anything. The question is: is this thing core or context for us? And if it is context, then building it means spending your scarcest resources becoming mediocre at something a specialist has already perfected, while your competitors spend theirs on what actually differentiates them.

Here is where property CEOs get into trouble. The instinct is to say that everything about how we run buildings is core, because it is our business. But that conflates the business with the differentiator. Every property company collects rent, posts it to a ledger, closes its books, tracks work orders, and reconciles across entities. Doing those things well matters enormously. But doing them in a way that is meaningfully different from your competitors, differently enough to justify building and maintaining the software yourself, is a much stronger claim, and it is usually false.

The genuinely core thing in a property business is more often what you do with the information those systems produce: which assets you buy, how you price, how you decide where to put capital, how you keep good residents. That is where a distinctive advantage lives, and it is worth protecting fiercely.

The three costs a CEO underestimates

Even when building is right, it costs far more than the number in the proposal, and three costs are systematically missed.

The maintenance tail. Software is not built once. The rule of thumb across the industry is to budget 15 to 20 percent of the original build cost every year, forever, just to keep it working. A five-hundred-thousand-dollar internal tool is a seventy-five-to-hundred-thousand-dollar annual commitment for as long as the business runs on it. Most build proposals present the construction cost and go quiet about the mortgage.

The opportunity cost. This is the one that should trouble a CEO most, because it is invisible in every business case. If your best technical people spend eighteen months building an internal maintenance system, that is eighteen months they did not spend on whatever would have actually moved the company forward. The proposal will tell you what the build costs. It will never tell you what it displaced.

The key-person risk. An internal tool becomes load-bearing. The people who built it understand it, and when they leave, that understanding leaves with them. A bought platform has a vendor with a support obligation and a roadmap. A built one has whoever is still around and remembers why it works.

None of these mean do not build. They mean that "we can build this cheaper than the license fee" is almost always an accounting error, and a CEO should insist on seeing the five-year number, including the tail, including the displaced work, before anyone starts.

The answer is usually neither, and that is not a cop-out

The framing of build or buy is itself part of the problem, because the pattern that actually works for most companies is neither pole.

The practical model is to buy the platform and build the differentiation on top of it. You do not construct your own general ledger, because a ledger is context and mature products have solved it far better than you will. But you also do not accept a rigid product that forces your genuinely distinctive processes into someone else's shape, because that is where you would be surrendering the thing you actually compete on.

What you want is a foundation you did not build, with room above it for the parts that are yours. That is why the question a CEO should be asking vendors is not "does your product do what we need today," but "can we extend this to express what makes us different, without leaving the platform." Those are very different questions, and only the second one protects your core while letting you buy your context.

This also resolves the emotional pull of the build argument. The instinct to build usually comes from a real frustration: the products on offer do not fit how we work. That frustration is legitimate. But the answer to it is rarely to construct everything from scratch. It is to stop buying rigid products and start buying extensible ones, so the fit problem gets solved without you taking on the burden of becoming a software company.

What a CEO should actually do with this

Three things, and none of them are technical.

Decide, personally, what is core. Not what is important, everything is important, but what is genuinely differentiating. Write it down. It will be a short list, and it will probably not include the things people are currently proposing to build.

Insist that every build proposal show its five-year cost with the maintenance tail and the opportunity cost named. If the proposal cannot articulate what the team will not do because of this build, it is not finished.

And then draw a hard line: build only above the line you drew, and buy everything below it, from vendors who let you extend rather than forcing you to conform.

The property companies that get this wrong do not usually fail dramatically. They just spend years and a great deal of money building competent versions of things they could have bought, while the capability that would have actually distinguished them stayed on the roadmap. Meanwhile the company down the street bought its context, built its core, and pulled steadily ahead for reasons nobody could quite put a finger on.

That is why this is not an IT decision. IT can tell you what is possible. Only you can say what this company is supposed to be better at than everyone else, and every build-versus-buy call is really an answer to that question, whether or not anyone says it out loud.

Frequently Asked Questions

Q1. Why is build vs buy a CEO decision rather than an IT decision?
Because the question underneath it is what your company is genuinely differentiated by, and that is a strategy question only the CEO can settle. Forrester found 67 percent of software projects fail due to the wrong build-or-buy choice itself rather than poor execution, which means the decision, not the engineering, is where most of the risk sits.

Q2. When does building actually make sense?
When the capability is genuinely core, meaning it directly creates your competitive differentiation and no available product can express it without destroying what makes it valuable. McKinsey found high performers build over 90 percent of their differentiating applications internally. The test is not whether you could build it, but whether it is the thing you win on.

Q3. What is core versus context?
Geoffrey Moore's distinction: core activities directly create competitive differentiation, while context activities are necessary but not distinguishing. Payroll, email, and for most property companies the general ledger, are context. Building context means becoming mediocre at something a specialist has already perfected, using resources your competitors are spending on their core.

Q4. Isn't everything about how we run our buildings core to us?
That conflates the business with the differentiator. Every property company collects rent, posts to a ledger, and tracks work orders, and doing those well matters enormously. But doing them in a way meaningfully different from competitors, different enough to justify building and maintaining the software yourself, is a much stronger claim and usually not true.

Q5. What costs do CEOs typically underestimate in a build?
Three. The maintenance tail, roughly 15 to 20 percent of the build cost annually, forever. The opportunity cost, meaning whatever your best people did not do while building it, which never appears in a business case. And key-person risk, because an internal tool's understanding walks out the door when its builders do.

Q6. Is there a middle path between building and buying?
Yes, and it is usually the right one: buy the platform, build the differentiation on top of it. Do not construct your own ledger, but do not accept a rigid product that forces your distinctive processes into someone else's shape either. The question to ask a vendor is whether you can extend their platform to express what makes you different without leaving it.

Q7. Our current products don't fit how we work. Doesn't that mean we should build?
It means you should stop buying rigid products, not that you should become a software company. The frustration is legitimate, but the remedy is usually an extensible platform rather than a ground-up build, which solves the fit problem without taking on the maintenance, opportunity, and key-person costs of owning everything yourself.

Q8. How do I make this decision rigorously?
Personally define what is genuinely core, and keep the list short. Require every build proposal to show its five-year cost including maintenance and to name explicitly what work will be displaced. Then build only above that line and buy everything below it, choosing vendors who allow extension rather than demanding conformity.