The build vs buy software decision used to hinge on cost and time. In the AI era it hinges on judgment, which makes it a harder call, not an easier one.
AI has changed the conversation around software fast. What used to be gated by technical skill is now open to almost anyone. You can prompt an AI tool and get working code or a prototype in a fraction of the time it once took.
That shift is real, but it can mislead. Lowering the barrier to generating code does not remove the hard part of software strategy. It just moves where the difficulty sits.
As Josh Anderson, CTO, puts it, the cost of producing code is approaching zero, but that does not make building the right solution any easier.
The actual writing of the code is no longer the scarce skill. — Josh Anderson, CTO, DecisionPoint Technologies
This conversation with Eric Hilton, VP of Solutions and Marketing, closes the modernization series. It assumes you have already worked through where you are on the curve and what AI readiness demands. Here the question is how to decide what to build, what to buy, and why.
Prefer to watch? Watch the full conversation above, or jump to a section using the chapter timestamps.
Watch the full conversation
For years, software was defined by scarcity. Skilled developers were hard to find, timelines were long, and implementation was tied to how much code had to be written and maintained.
That logic shaped how organizations invested: buy proven tools where possible, and build only when the requirement was truly unique.
AI is breaking that model apart. Producing code is becoming faster and cheaper, so the bottleneck has moved. The scarce resource is no longer engineering labor.
It is the ability to define a business problem clearly, describe how a solution should work, and make good calls about workflows and long-term fit.
That is why this moment matters for leadership teams. If anyone can use AI to produce an application, the differentiator is no longer access to code. It is knowing what is worth building in the first place.
Companies that understand their operating model deeply can turn AI into an advantage. Those without that clarity can move fast in the wrong direction.
The immediate question leaders are asking is whether AI changes the traditional build-versus-buy equation. On the surface it seems like it should. If code is cheap to generate, why keep paying for rigid platforms or licenses that only partly fit?
It is a fair question without a simple answer. Buying has always offered speed, standardization, and lower risk. Building offered flexibility and differentiation at a higher cost, plus a maintenance obligation many teams underestimated.
AI compresses development time, but it does not remove the need for ownership, governance, and ongoing refinement.
That is why the customization question matters. Easier development does not turn custom software into an easy button. As Josh frames it, build is not a transaction. It is a commitment.
The choice is not just whether you can get something live, but whether you want to own shaping, maintaining, and evolving it over time.
So not every company should build just because it now can. Some have the expertise and appetite to do it well. Others are better served buying, configuring, and selectively extending proven tools, often with a partner who knows the domain.
The arrival of AI does not make those companies less strategic. It just shifts the criteria toward differentiation, control, maintenance, and long-term fit.
AI can execute on a clearly defined problem. It can generate code, surface options, and speed up design.
What it cannot do is define the business problem with enough rigor to make the result meaningful. That still depends on people.
Josh makes a key distinction here: the knowledge that drives a useful solution cannot live in the heads of a few individuals. It has to be institutional. If only the people currently doing a process understand it, that is a weak foundation for transformation.
This is also why software and operations can no longer be separate conversations. If a company simply digitizes an outdated workflow, it gets a cleaner version of the same inefficiency.
The stronger move is to treat software and process design as one exercise. As Josh puts it, you may not need prettier pick slips. You may not need pick slips at all.
One useful tension in this conversation is that AI speeds some things up while forcing others to slow down. Coding can move dramatically faster, a feature that took weeks might take hours, but that speed changes the rhythm of development.
In a slower cycle, natural checkpoints catch mistakes: define requirements, build in increments, review, fold in feedback. When the build cycle compresses, that pacing disappears, and it becomes easy to outrun the feedback loop and bake in the wrong assumptions from the start.
So the planning burden moves upstream. The teams that benefit most from AI are not the ones that move fastest, but the ones that get more disciplined before the build begins, clarifying the problem and pressure-testing assumptions.
Used well, AI is a tool for interrogation as much as acceleration, useful for stress-testing a design before resources are committed.
AI is not removing the need for strategy, expertise, or disciplined execution. It is raising the value of all three. As the cost of producing code falls, the quality of the thinking behind it matters more, not less.
The advantage will not come from building faster for its own sake. It will come from knowing where custom capability truly matters, where proven tools still make sense, and how to align people, process, and technology around outcomes instead of habits.
If your organization is weighing how AI fits a mobile-first operating model, start where this series began. Revisit modernization readiness and AI readiness, then see how DecisionPoint helps organizations design and optimize mobile-first operations.
