How do you evaluate the trade-offs between custom and off-the-shelf enterprise software?

A mentor once taught me a crucial business principle that continues to shape my decisions: 'build for advantage, buy for parity'. This principle is particularly relevant in the context of software development. Custom software can undoubtedly offer unique benefits. However, it's essential to consider the maintenance aspect, often underestimated. For instance, when developing a mobile app, one must keep up with the continuous updates required by dynamic platforms like iOS, Android, and Windows. We must weigh the benefits of bespoke software against the ongoing commitment that off-the-shelf solutions might spare us. This way, we can ensure we make informed decisions that truly serve our business needs.

Before you build something, rule out the potential that something exists that meets your primary requirements. Often teams will say there is no existing solution that meets their needs, because their requirements aren't based in reality. This is common with software development teams who have the skills to build "anything", and don't want to settle. But rarely will anything meet 100% of your requirements, even if you build it yourself. Leaders should expect that anything you decide to build will cost more than you expect, take longer than anyone has time for, and ultimately be less capable than you were promised. Put simply: in the age of SaaS and rapid time to market, "build" should be a last resort for nearly every situation.

The normal expectation that off the shelf software is cheaper is going to change, given the low/ no code/ ai revolution. Buying an off the shelf software and adapting may be more expensive than rapidly modeling an app on a low code platform and deploying this. Saas software may seem cheap initially but once drawn in the cost of more users and premium versions and cloud usage lock ins make it expensive over the life time of usage. Low code is now ready for the shown down. Am writing after doing it in a number of situations. Check out www.stragiliti.net. Get a quote from us and compare it with an off the shelf software. The above challenge applies for enterprise class unique apps and not standard area like accounting, payroll, crm etc.

In my experience you'll typically get at least 70-80%+ of your requirements met from an OOTB solution - so the question then becomes - is it worthwhile to spend 100% of the money (and significant amounts of time) to custom build an alternative only to receive a 20-30% incremental benefit? When you look at the costs through this lens, the idea of a bespoke solution almost never makes sound business sense.

Look at what separates you from your competition, gives you a competitive advantage or makes you unique. I agree w the previous comments that 70-80% of your process will typically be supported by OTS applications, so how to address the remainder needs to be considered in light of whether it provides competitive advantage. If so, it's worth considering custom (or customize the OTS - but that's a different discussion), and keeping your current processes; if not, adapt your processes to what the OTS software supports, in most cases those are built on best practices anyway. There's no need to re-invent the wheel, and in most cases, a general function like AP or AR is not providing a company their competitive edge.

The primary reason that companies pursue custom software is because there is no off-the-shelf software which meets their unique needs. A few core functions, like accounting, are generally consistent across industries and departments, and off-the-shelf software works great for those. However, most companies are doing unique things that given them competitive advantages, and those unique things require custom software tools.

Custom software may not always provide the flexibility as described. An application designed to initially support a specific process may require significant development if that process changes, or to support a similar process for a different customer organization/client.

I believe it is important to know your core business. Third-party solutions can significantly accelerate your product development when it's about very generic or standard features and workflows. Even within a very domain-specific workflow you find common steps that could benefit from standardization instead of customization. When you are using your resources for very standard parts of software, you risk delaying your time-to-market.