Every leader eventually faces the same question about a piece of software the business needs: do we build it, or do we buy it? The honest answer is that “buy” has quietly become the default – not because it is always right, but because building has historically been slow, expensive, and risky. Low-code changes that math. This playbook gives you a repeatable way to make the call on the merits, capability by capability, rather than on habit. There is a decision step partway through you should be able to answer with confidence.
Who this is for
Enterprise and mid-market leaders – and the architects who advise them – deciding how to deliver a capability the business is asking for. That might be a single application, a workflow spanning three systems, or a portfolio decision about where to invest engineering effort over the next two years. The framework works at any of those scales. Run it once on the decision in front of you, then reuse it.
The framework: two questions, not one
The build-vs-buy debate usually collapses into a single argument about cost, and cost is the wrong place to start. Start instead with two questions, scored independently for each capability you are considering:
- How differentiating is it? Does this capability shape how you actually compete and win – your pricing engine, your claims workflow, your customer onboarding, the thing your competitors cannot copy off the shelf? Or is it plumbing that every company in your industry runs more or less the same way?
- How often do requirements change? Is this a capability you will refine every quarter as the business learns, regulations shift, and customers ask for more? Or is it stable, well-understood, and unlikely to move for years?
Score each on a simple 1-to-5 scale. Differentiation runs from “pure commodity, everyone does it the same” (1) to “core to how we win, unique to us” (5). Rate of change runs from “set it and forget it” (1) to “we will be changing this constantly” (5). Two numbers per capability is enough – resist the urge to over-engineer the rubric.
The 2×2: where each capability lands
Plot the two scores against each other and four quadrants appear. Each points to a different default answer:
- High differentiation, high change – build. This is your competitive edge and it moves constantly. Owning it is the point. A packaged product will always lag your needs, and every gap becomes a customization you pay for forever.
- Low differentiation, low change – buy. Commodity capability that rarely moves – payroll, general ledger, email, expense reports. Someone else has already built it better than you will, and maintaining your own version is pure cost with no upside. Buy without guilt.
- High differentiation, low change – build carefully, or buy and extend. It matters to how you compete but it is stable. Building is defensible if no product fits; often a strong product plus a thin custom layer is the pragmatic answer.
- Low differentiation, high change – this is where low-code earns its place. Not a differentiator, but it changes so often that a rigid bought product fights you at every turn and traditional custom code is too slow to keep up. A configurable, quickly-changed low-code app is frequently the best fit.
Decision step: before going further, place every capability in the decision on this grid with a rough two-number score. If everything lands in “buy”, you probably do not have a build problem. If your most differentiating, fastest-moving capabilities are sitting inside a bought product you keep customizing, you have found the thing worth building.
How low-code changes the math
Here is the shift most build-vs-buy advice has not caught up to. The old logic said: building is expensive and slow, so unless a capability is deeply strategic, buy it and live with the compromises. That logic assumed traditional hand-coded software – long timelines, large teams, high maintenance.
A low-code platform like Mendix changes the inputs. When building is genuinely fast and cheap enough – visual development, a model non-specialists can read, one-click deployment, upgrades handled by the platform – then “buy” is no longer automatically the cheaper option for a differentiating app. The break-even point moves. Capabilities that were previously “not worth building” because custom code was too expensive become worth building, because you can deliver them in weeks, own them outright, and change them the moment the business needs to. This does not mean build everything – it means the honest answer tilts toward build more often than it used to, precisely for the capabilities where owning and changing them matters.
Total cost of ownership: count the whole life, not the launch
Whichever way you lean, cost the decision honestly – and that means more than the price of getting to launch. The comparisons that go wrong almost always pit a build estimate against a buy license fee and stop there. Count all of it:
- Build cost and run cost. The initial build is the small number. The larger one is running and maintaining it for years – fixes, enhancements, platform upgrades, the team that keeps it alive. A cheap build with expensive maintenance can lose to a pricier one that is easy to change.
- The real cost of “buy”. Licensing rarely stands alone. Add implementation, integration, mandatory customization, per-seat costs that scale with growth, annual increases, and the internal effort to administer it. The sticker price is the beginning of the conversation, not the end.
- The cost of the gap. When a bought product does 80 percent of what you need, the missing 20 percent does not disappear – it becomes workarounds, shadow spreadsheets, integrations, or expensive vendor customizations. For a differentiating capability, that gap is exactly where your advantage should live.
- Lock-in. Both paths lock you in – to a vendor’s roadmap and pricing on the buy side, to a platform or codebase on the build side. Ask the honest exit question: if this choice stopped working in three years, how hard and how expensive is it to leave? Low-code carries platform lock-in too; weigh it against the speed and ownership you gain.
- Who owns the knowledge. The factor most often ignored, and the one that hurts most later. When you buy, the vendor owns how it works. When you build – traditional or low-code – you can own the knowledge, but only if the work is documented and your people understand it. A build that lives in one contractor’s head is its own kind of lock-in.
When to build, when to buy, when to low-code
Pulling the framework together into plain guidance:
- Build (traditional or low-code) when the capability is differentiating and changes often – it is how you compete, and you need to keep changing it on your own timeline.
- Buy when the capability is a commodity that rarely changes – a mature market already solves it well and owning your own version is cost without upside.
- Reach for low-code when you need to build fast and keep changing – differentiating apps you want to own, or high-change capabilities where a rigid bought product cannot keep pace and full custom code is too slow. Low-code is also the pragmatic middle for “build and extend” cases: a thin, ownable layer of differentiation around the commodity systems you bought.
What trips teams up
- Defaulting to buy on habit because “building is always more expensive” – a belief that low-code has quietly made untrue for many capabilities.
- Comparing build cost against buy license and calling it a business case – ignoring run cost, integration, the 20 percent gap, and lock-in on both sides.
- Buying a product to run a differentiator and then paying, forever, to customize it toward the thing you should have built.
- Building the commodity – sinking senior engineering effort into payroll or a ledger that a mature product does better and cheaper.
- Confusing “we can build it” with “we should” – low-code makes building easy, which makes discipline about what to build more important, not less.
- Building a black box – shipping something nobody documented, so the knowledge walks out the door with the contractor and you are locked into your own code.
The decision checklist
- Every capability in scope scored on differentiation (1-5) and rate of change (1-5).
- Each capability placed in a quadrant, with a default answer for each.
- For “buy” candidates: confirmed a mature product genuinely fits, with the gap priced honestly.
- For “build” candidates: confirmed it is differentiating and worth owning – not just something you can build.
- Full cost of ownership modelled for the leading options: build and run, or license plus implementation, integration, and growth.
- Lock-in and exit cost assessed for both paths, low-code platform lock-in included.
- A clear owner of the knowledge named – and, for any build, a documentation-first plan so you actually keep it.
- The default answer challenged at least once: if the framework says build, could a product plus a thin layer do it? If it says buy, is a differentiator hiding inside?
How Golden Earth helps
We are a senior Mendix consultancy, but our first job on a build-vs-buy question is not to sell you a build – it is to help you make the honest call. Sometimes the answer is buy, and we will tell you so. Where the answer is build, we build the parts genuinely worth building: the differentiating, fast-changing capabilities where owning the software is the point. We work senior-led and documentation-first, embedded in your team, so that when the project ends you own the knowledge and the application – not a black box you have to keep paying us to understand. If you are weighing a build-vs-buy decision and want experienced people to pressure-test it with you, talk to an expert.