Every technology leader has made a version of this decision: buy the accounting package or build one, buy the CRM or wire together your own, sign the five-year enterprise agreement or put a small team on it internally. It's one of the most consequential calls an architect makes, and for good reason — get it wrong and you either spend years building something you could have bought, or you force your business's processes to fit a vendor's model because ripping it out later is too expensive to contemplate.
This is the final part of our series on Chris Ford's O'Reilly Early Release book Agentic Engineering at Scale. The earlier parts covered the harness framework, reverse engineering legacy estates, spec-driven development and keeping systems fit. This piece closes the loop on economics — and it's the part of the book most directly relevant to how South African organisations run tenders, RFPs and vendor selection.
The classic heuristic still mostly holds
The standard advice hasn't changed: build what differentiates you, buy what doesn't. A payroll system isn't a differentiator for a manufacturer — nobody chooses a car based on how the factory workers got paid, so a generic solution is fine. For a payroll vendor, the same system is the entire business.
What's changed is one of the quiet assumptions underneath that heuristic: that the market is ready to sell you a decent commodity solution to a generic problem. Sometimes it isn't — a vendor hasn't found the niche yet, the local market is too small to attract a mature player, or the compliance requirements (POPIA, sector-specific regulation, B-BBEE reporting) are specific enough that generic international tools don't fit well. When it's genuinely cheaper to build something your business regards as a differentiator, you don't have much choice — but you can scaffold: a small, low-commitment build to tide you over, with an explicit plan to replace it once the market catches up.
Three ways coding agents destabilise the old dynamics
Cheap code doesn't invalidate the buy-versus-build heuristic. It changes three of its inputs materially enough that the process built around it needs to change too:
Building got cheaper, which shifts more capabilities into the range where building is realistically viable — including narrower use cases that would never have justified a full development team before.
Code is being decomposed from the service around it. A SaaS vendor used to sell you code and the operational service running it, bundled. Increasingly, the code part alone is reproducible cheaply. What survives is the part that was never really about the code — genuine expertise, data network effects across a whole client base, real-world physical integration (an airline that owns the plane; a logistics vendor that owns the trucks). Ford calls this the shift from software-as-a-service to service-as-software: the value was never really the software, it was the service the software happened to deliver.
Reversal costs less. This is the one worth sitting with, because it's the actual mechanism behind everything else in this article.
Grow: not a third option, a strategic posture
The book's proposed answer isn't a tidy third box next to Buy and Build. It's a mode of operating — Grow — where the actual goal isn't getting each individual buy-or-build call exactly right up front. It's managing the consequences of that call cheaply enough that getting it wrong isn't a crisis.
Jeff Bezos's "two-way door" framing from his 2016 shareholder letter is the clean way to think about this. A one-way door — a decision that's very expensive to reverse — deserves careful, slow deliberation. A two-way door doesn't, because you can walk back through it if you're wrong. What coding agents change, when the surrounding architecture supports it, is how many buy-versus-build decisions are genuinely two-way doors rather than one-way ones.
In practice, that means: buy a vendor on a shorter contract than you would have five years ago, because you can afford to reassess sooner. Buy with clear interface boundaries so a future switch — to building it yourself, or to a different vendor — doesn't require reverse-engineering your own integration first. Keep your organisation's actual leverage point on the interfaces between systems, not on locking in every implementation choice underneath them.
What this means for how you run procurement
This is where the theory turns directly into changed practice for tender and RFP processes, and it's the part we think South African procurement teams should be paying closest attention to right now.
Try before you buy, properly. Coding agents make it realistic to build a genuine proof of technology against a shortlisted vendor's product — not a slide deck, an actual integration — before you commit. That directly addresses what economist George Akerlof called the "market for lemons": when buyers can't verify quality before purchase, the market degrades toward the cheapest, most aggressively marketed option, because good vendors can't prove they're better and eventually stop trying. A real trial breaks that dynamic in your favour, and rewards vendors who've actually built something good over vendors who've just invested in a slicker pitch.
Price the exit, not just the entry. Traditional procurement scoring focuses almost entirely on implementation cost. The Grow mindset asks the other question just as seriously: what does it cost us to leave this vendor in two years if we need to? What proprietary data formats are we accepting? How much vendor-specific logic will end up embedded in our systems? Get that estimate before you sign, not after you're already locked in.
Shorten contracts deliberately. If reassessment is genuinely cheaper than it used to be, locking in a five-year term to shave a 5% discount off the price is usually a worse trade than it looks on the page. It's giving up the flexibility that's precisely what's now valuable.
Demand agent-friendly systems from vendors. Configuring and extending commercial off-the-shelf software is real work, and it's work your coding agents can now help with directly — but only if the vendor's product has clean APIs, decent documentation, and genuine extensibility rather than a closed black box. Make that a real line item in your scoring matrix, not an afterthought.
The long tail gets economically viable
One underrated implication: as the cost of building falls, use cases that never justified a dedicated build become worth doing. A provincial branch office with a genuinely different regulatory requirement. A single high-value workflow serving twenty internal users that would never have cleared an ROI hurdle before. This is Chris Anderson's "long tail" logic applied to internal software — the same shift that made niche products viable in retail is now making niche internal tools viable in enterprise IT.
The catch, and it's a real one: this only pays off if your organisation's interfaces and boundaries are clean enough to absorb more small, purpose-built components without the whole architecture becoming an unmanageable sprawl. The unit of modularity has to also be a realistic unit of deletion — a system that's easy to add to but impossible to safely remove pieces from just accumulates a different, quieter kind of technical debt. That's exactly the discipline Part 4 of this series was about.
Practical starting points for South African organisations
For teams running tenders and RFPs into 2026 and 2027, a few concrete shifts are worth making now, ahead of the market fully catching up:
- Add an explicit exit-cost estimate to your vendor scoring framework, not just an implementation-cost estimate.
- Where the decision is genuinely reversible, favour a shorter contract with a clear switching path over a longer one with a marginally better headline price.
- Build the proof-of-technology into your RFP process as standard practice, not an optional nice-to-have for the finalists.
- For capabilities in the grey zone — where you're not sure if it's a genuine differentiator — decompose rather than defaulting: buy the generic underlying capability, build the thin layer that's actually specific to your business on top of it.
Coding agents haven't made the buy-versus-build decision disappear. They've made getting it wrong cheaper to fix — but only for organisations disciplined enough to actually design and procure for that flexibility, rather than assuming it comes free.
How CloudNala can help
CloudNala helps organisations run tenders and vendor selection with exit cost priced in from day one — structuring RFPs, proof-of-technology evaluations and contract terms so a buy or build decision stays a two-way door, not a five-year commitment made on a slide deck.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Build My Supplier Pack or write to us at consult@cloudnala.co.za