Technical contribution
Many companies today use off-the-shelf software that isn't really a good fit for them. The decision to use it was made at a time when custom software development simply wasn't a viable option. Too slow, too expensive, too risky.
AI is changing precisely this situation. Development is becoming faster, more cost-effective, and scalable for smaller teams. What was previously considered too resource-intensive is becoming increasingly feasible—even for small and medium-sized businesses.
But economic feasibility alone is not a reason to choose Make. The real question is a strategic one: Which systems map core processes that no vendor is familiar with, and that therefore must be developed in-house?
For over two decades, one clear preference dominated: buy whatever you can. Off-the-shelf software, SaaS platforms, best-of-breed tools. Custom software for businesses was considered the exception because it was resource-intensive, difficult to scale, and often riskier than the benefits justified.
Under these circumstances, “Buy” was the sensible response, but not a strategic one. Many companies have adapted to standard processes that didn’t really fit their business.
AI is changing three key factors that previously made Make unrealistic:
A GitHub study on developer productivity shows:
The extent to which this potential can be realized in practice depends on the organization's level of maturity, its architecture, its data strategy, and the experience of its developers.
It’s not just the technology that’s changing; the role of developers themselves is shifting as well. Today, we talk about “forward-deployed engineers” or “embedded engineers”: software developers who are embedded directly within the business, working in a distributed manner—right where value is created. This proximity to business processes is one of the prerequisites for ensuring that custom software development creates a real competitive advantage—and doesn’t just function.
What used to take several developers months to build can now be implemented in a matter of weeks. This means that the economic rationale behind the “buy” preference no longer holds true—not for all systems, but for more than many small and medium-sized businesses currently anticipate.
However, economic feasibility alone does not justify Make. Another criterion is decisive: Which systems map out the business processes that set a company apart from the competition and for which there is no standard solution?
Off-the-shelf software requires standard processes. Those who adapt to these processes gain efficiency but relinquish strategic control. The advantages of custom software become apparent when the software maps a company’s unique business processes—processes not included in any off-the-shelf product. This is the main difference between custom software and off-the-shelf software.
That is why Make is not a general preference. It is a deliberate choice for areas where custom software makes a difference and dependence on a single vendor becomes too costly.
Anyone seriously considering custom software development today will quickly run into the real hurdle. It rarely lies in the technology, but rather in the foundation.
Make fails when the foundation is missing:
If any of these elements is missing, it creates a level of complexity that outweighs the benefits of developing custom software. In this environment, AI does not accelerate value creation—it accelerates chaos.
Anyone who takes “Make” seriously as a strategic option must therefore first answer another question: Is the foundation solid? Is the organization already capable of conducting AI-supported software development, or is it still operating on a “Prompt & Pray” basis? The platform is a prerequisite for the “Make or Buy” decision, not its consequence.
(If you're wondering what this foundation actually looks like, we've covered that in this post.)
For a long time, the classic “make-or-buy” debate centered on feasibility: Can we build this ourselves? Do we have the capacity? Is it economically viable?
These questions aren't wrong. But they are no longer the most important ones.
With AI, the make-or-buy strategy is shifting from feasibility to strategy: it’s no longer “Can we develop this ourselves?” but rather “Where does our own software determine our competitive advantage?” Which systems contribute to our own value creation, and which are infrastructure that others are better suited to operate?
For example, a company with specific requirements for a CRM system might choose the “do-it-yourself” approach—implementing a solution on its own using Agentic Engineering—rather than heavily customizing a SaaS solution. In other cases, a standardized SaaS solution is exactly the right choice. Of course, even good SaaS providers are improving thanks to AI transformation. Nevertheless, the criteria that previously guided decision-making are shifting and must be reevaluated.
Make-or-buy is therefore no longer an IT issue, but a strategic one. Those who consciously address this question today invest strategically and relinquish control only where it makes sense to do so.
Reevaluating the make-or-buy decision is a strategic process, not a tool upgrade. As a data and AI consulting firm, we help companies tackle their AI transformation, assess their maturity level and potential, identify the right systems, and set up customized software development in a structured way—from empowering their own developers to scalable, agent-based implementation.
For more insights, visit our page on AI in software development —or contact us directly.
It’s worth it in situations where software supports unique processes and no standard solution is viable. AI makes this possible even for budgets that wouldn’t have been sufficient in the past.
With largely standardized processes and reliable vendor roadmaps, “Buy” remains a valid option for infrastructure and non-mission-critical areas.
AI significantly reduces the effort, time, and complexity of in-house development by speeding up code generation and reducing the amount of manual work required for routine tasks. As a result, “Make” becomes economically viable in more areas than before.
Rarely is it the code. More often than not, it’s an unclear foundation consisting of the platform, data strategy, and governance.
By honestly assessing your own level of maturity and having a clear understanding of the value you create. Only then should you make decisions regarding architecture and vendors.
As a partner at Dataciders, Christopher Klewes helps companies structure their software development and data platforms in a way that enables AI to scale effectively. His focus is on integrating architecture, platforms, and engineering processes to establish AI not merely as a tool, but as a controllable driver of the business model.
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus.
“Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus.”