Anyone can code!

At Mulberry, we often are called in to help organisations 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.

 Unfortunately, these endeavours usually end poorly, leading to difficult management conversations and strategic 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
• Gen AI makes it even easier to generate and test code

 (3) Frustrated IT leaders with technology-driven aspirations

 IT leaders of "traditional" enterprise are pressured to demonstrate innovation and provide more "thought leadership" by their peers, who are fed constant waves from industry to embrace whatever is the latest hype (e.g. Gen 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.  They would dearly love to work with the latest technology.

 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 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, but not yet. The best talent is     either working for startup, working for the cloud providers, or working for themselves. Why would they work for a traditional enterprise?
  ‍
• 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.
 

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 thatseems to have a higher rate of success.

 (2) It is sometimes possible to improve the parametersand 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 abetter 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 thatwhat 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.

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, organizations can make more strategic technology investments that align with their core business strengths while avoiding costly development pitfalls.

‍

‍