At Mulberry, we often are called in to help enterprises who are attempting or have attempted to build core systems. By core, we mean those central to the successful day-to-day operations of the business. These are the systems tied to critical business processes for example customer sales, payroll, or order management. By enterprise, we are referring to traditional enterprises, where the product or service is not exclusively digital (think retailers, manufacturers, energy suppliers)

Unfortunately, these endeavours to develop software usually end poorly, leading to difficult management conversations and costly recovery efforts.

This article explores the reasons behind these decisions, the challenges faced, and provides recommendations for a more balanced approach.

The Allure of Building: Understanding the Rationale

Enterprises typically justify the decision to build core systems based on three main arguments

(1) There is a lack of suitable off the shelf options in market

In some cases this can genuinely be the case. If a business model is genuinely unique, then there won't be off the shelf solutions available and the software is the core IP of the business. This can also be true geographically when solutions aren't available in market. Oracle is great in the US. SAP is great in Europe. Neither have historically been great in Asia Pacific.

(2) Perceived ease of custom development.

Major cloud vendors and their partners often market that building custom software development is easy, highlighting

  • that software development tools have evolved constantly over many years, and offer fantastic tools for developers
  • that the cloud makes deployment and infrastructure simpler
  • AI makes it obscenely easy to generate and test code. An agent can scaffold a working prototype in an afternoon that previously used to take a fortnight.

(3) Frustrated IT leaders with technology-driven aspirations

IT leaders of "traditional" enterprise are under constant pressure to demonstrate innovation and "thought leadership". Mostly, this comes courtesy of boards, who are fed constant waves of FOMO (fear of missing out) from consultants and software vendors, and pressure to embrace whatever is the latest hype (e.g. AI).

The reality for an Enterprise IT Leader is that they are burdened with maintaining a significant amount of legacy technology that is used to run the business day to day, which is usually the cumulative history of decades of FOMO based decisions. All seemed "forward thinking" at the time, but now cannot be simply "turned off" and replaced by the latest incarnation.

At a more practical level, working with the latest technology helps CIO's maintain their own profile and next opportunity. No-one wants to hear about how efficiently you maintained 20 year old software. Even though that is often the best economic outcome a CIO can create.

(4) Dissatisfaction with existing vendors

Long upgrade times, costly maintenance, lack of service, poor account management, lock in, lack of key functions, slow to digitise, bad partners, clumsy RFP responses…it's a long list of disappointments.

The sum of these factors creates an environment where the easiest path is just to placate to the board, and build your own, regardless of economics or value creation opportunity.

‍

The Reality : Why Building Often Fails

It turns out, coding is the easy bit. As the chef in Ratatouille said : Anyone can code! The harder bits are everything else.

  • To make anything useful, you need great product management skills, a fantastic understanding of the enterprise, comprehensive stakeholder management, brilliant governance and consistent access to funding. And you need to sustain this for longer than you think.
  • Creating a software product is not a core competency for enterprises where software is not the main product. Retailers, restauranteurs and utility providers are necessarily good at retailing, hospitality and producing energy.  Investors are not asking these companies to be great software engineering organisations, they are asking them to be good at their core competencies.
  • You will be fighting for scarce software engineering talent. AI may eat the software engineering industry at some point. The best talent is either working for a startup, working for the cloud providers, or working for themselves. Why would they work for a traditional enterprise?

    2026 Update : Since this article was first published, agentic coding tools have moved from a novelty to something enterprises use each day. Code creation is quickly becoming free. Nevertheless, the parts of a software build that were never about typing code still hold true - deciding what to build, running change management, aligning stakeholders, securing funding and carrying the ongoing cost of constant change.
    ‍
  • The people needed to build good software are the same people that are ensuring the company can run successfully. These are the people that  truly understand the business and it's competitive advantage. These are the people that make bread. You are competing for time and attention.
    ‍
  • Ongoing costs are always higher than you think. Keeping the software secure, patching, compliant and reliable, retaining suitable talent, rebuilding and refactoring code to be current and secure takes a lot more work (and costs a lot more) than you think.
    ‍
  • Technology changes quickly. Building a client server application in 2005 was a good idea for the time. Technology moves astonishingly quickly.  By the time you finish the build, technology will have already moved on, and you are left supporting the technology of the day, not the technology of tomorrow. The people will move on as well. Once the platform is built. The talent will move on to the next, far more interesting, project.
    ‍
  • AI makes code development an even lower barrier to starting. However what gets built, will still need to be secured, maintained, and eventually replaced once the technology moves on again.

Three recommendations

Building software is a difficult path, and considering the complete economic picture and total cost of the challenge is important.

This doesn't mean that buy is without its challenges either, and the answer is typically more nuanced.

Consider the following strategic approaches

(1) A strategy of buy for commodity, build for unique IP.

If Finance or HR is not your core business, then it's better to buy ERP's and HRIS systems off the shelf and adjust your processes accordingly.  If there is something that is unique that represents your competitive advantage, or a component of it (in conjunction with people or process as an example), it may be a candidate to buy

It can be a bit difficult to know what is core. If I think my customer service isa competitive advantage, shouldn't I build my own CRM system? It requires some deeper thinking. Customer service may be my competitive advantage, but transacting sales and taking payments is probably not.

Building front end customer and employee digital experiences "presentation layers" that access bought core systems is a more nuanced approach that seems to have a higher rate of success.

(2) It is sometimes possible to improve the parameters and radius of the "Buy" option

In the spirit of you get out what you put in, you can work with vendors to improve their capability for mutual benefit, so that you can help yourself. But isn't that what we pay for? Well it is, but we at Mulberry believe in the practical reality that not all vendors are perfect, and actively collaborating is a better option than watching them fail.

(3) Start with end in mind

Approach custom development with the understanding that what you build becomes legacy the moment it goes live. This mindset encourages appropriate guardrails around scope and architecture, acknowledging the rapid depreciation of technology assets. Planning for maintenance, evolution and eventual replacement from the start leads to more sustainable technology investments. Consider the idea that what you build will immediately become legacy the minute it goes live.

Summary

At Mulberry, we've seen the challenges enterprises face when building core systems first hand. While the allure of custom development is strong, whether due to perceived market gaps, technological optimism, leadership ambitions, or vendor frustrations, the reality often falls short of expectations.

The true difficulty lies not in coding itself but in sustaining the comprehensive ecosystem needed for successful software development: product management, stakeholder alignment, governance, funding, and specialised talent that most enterprises aren't structured to maintain.

AI challenges this even more, with code essentially now "free". The risk of code sprawl is high. More code is not always the answer. Particularly when it is linked to automating a broken process, or consuming expensive tokens or creating security risks.

We recommend a balanced approach: buy commodity systems while building only for unique competitive advantages; actively collaborate with vendors to improve their offerings rather than replacing them; and approach any custom development with clear awareness of technology's inevitable depreciation cycle. By acknowledging these realities, organisations can make more strategic technology investments that align with their core business strengths while avoiding costly development pitfalls.