Buy vs Build: Has the Tipping Point Moved?
The question hasn't changed. The answer might have.
The buy vs build question has been around for most of my career. In my experience it was mostly asked in larger organisations, or in smaller ones with technical people on hand. A lot of other businesses never asked it at all. They bought what was available and adapted around it.
I've been wondering whether the trade-off behind that question still looks the way it used to. Technology has moved on, and the tipping point between buy and build may have moved with it. If so, it may be a question that more businesses can now ask, not only the ones with technical people on hand.
A bee doing its bit to make some apples I’ll be eating in 6 months time
The old trade-off
Buying is often the sensible default. You get something working quickly, someone else maintains it, and the cost is predictable. The price is fit. Software built for thousands of customers tends to reflect the average business, and few businesses are average. So people adapt their processes to the software, bolt spreadsheets onto the gaps, or re-enter data between systems that don't talk to each other.
Building promised the opposite: software shaped around how you actually work. But building from scratch often meant a long runway, a large upfront cost, and an ongoing dependency on the people who wrote it. Sign-in, security, hosting, data storage, integrations: all of it had to be designed, built and kept running. For a lot of businesses, that was more than the problem justified.
Low code opened up the build side
Part of what has changed is the rise of low code platforms. If you haven't come across the term, think of it as building software out of Lego: ready-made pieces that you snap together and shape to fit, rather than making every piece from raw material. Shopify did something similar for ecommerce, where a business no longer has to build its own online shop from scratch.
Building used to mean hiring developers or engaging a software firm, which put it out of reach for many smaller businesses. Low code moved a good share of that work into visual tools. Screens, forms and workflows are assembled and configured rather than coded line by line, and a small team can often deliver something useful far sooner.
That has made building more accessible, more relevant and more possible for businesses that would never have considered it. It doesn't remove the need for good design. Low code is often easier to start than to structure well, and experience tends to show in the choices that don't look like much on day one. But building is no longer only an option for organisations with a development team.
We don't build from scratch
When I build with the Power Platform, I'm not starting with a blank page. The foundation is already there: sign-in through the Microsoft accounts people already use, security and permissions, a managed data layer, hosting, and connectors to the systems a business already runs. What's left to build is the part that is specific to the customer: their process, their rules, their screens.
That changes what "build" means. It looks closer to configuring and extending a platform than to writing software from scratch, and the cost, timeline and maintenance burden often look quite different as a result. Could that put building closer to buying on effort, while keeping the fit that made building attractive in the first place?
There's an ongoing side to this too. Part of the old cost of building was keeping the software running and current for years afterwards. On the Power Platform, Microsoft maintains the platform itself, so my customers' solutions can take advantage of platform improvements as they arrive, without anyone having to rebuild them. That's a different maintenance picture from a system that depends on whoever wrote it to keep it up to date.
AI adds weight to the "build on a foundation" side
This is where my experience and Microsoft's investment in the platform come together. Microsoft has put significant effort into building AI into the Power Platform and the wider Microsoft 365 environment. Because my customers' solutions sit on that foundation, they can often use AI natively with their own systems and data, rather than bolting it on afterwards or waiting for a vendor to add it.
Compare that with the alternatives. A bought package you can't extend may leave AI on the vendor's roadmap. A system built from scratch means wiring AI in yourself, along with everything that comes with it.
Experience still matters here. The platform provides the capability, but how a solution is designed often decides whether AI is useful or just a novelty: how the data is structured, what the solution connects to, and what guardrails are in place.
Where buying still makes sense
Not everything needs to be built. Highly regulated processes like accounting and payroll are often better bought. Compliance means the system has to be kept up to date with every regulatory change, and a vendor serving thousands of customers is often better placed to do that than a custom build.
A useful test may be whether the process is somewhere your business does things differently from its competitors. If it is, fit probably matters, and that's where building on a foundation could earn its place. If it isn't, buy.
It also doesn't have to be one or the other. Often the answer is a mix: bought systems for the regulated, compliance-heavy work, and a custom layer that connects them and gets more value out of what you already own.
Questions worth asking
If you're weighing buy against build, a few questions may help:
Which of your processes are specific to how you work, and which are driven by regulation?
Where are you adapting your business to fit the software, rather than the other way round?
If you built something, what would you be building on, and what would you have to build yourself?
How would AI work with the system you choose: natively, bolted on, or sitting on someone else's roadmap?
The tipping point may not sit where it used to. It's worth checking where it sits for you.
We use the AI Contribution Scale defined by Blair Enns to disclose the use of AI in our written content. This article is rated as: AI-4: AI Drafted. The content was drafted by Claude from our own content and ideas, we then refined the output.