In today's world there is a plethora of packaged software, software-as-a-service and customisable platforms that organisations seem less likely to consider the alternative option – custom-built software. Yet there remain many cases where custom-built software is both economically the better option and can differentiate your business or enable new capabilities.
To start with, of course, there are many cases where custom development makes no sense. One would have to be a little bit mad, for example, to write one's own operating system. Or you might just do it for the love of it – Linus Torvalds famously posted on Usenet back in 1991: "I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones." There are many of us who love to code on the weekend, and make things that already exist, just for fun, but this is not sensible for businesses.
It's also unlikely to be justifiable these days for an organisation to write their own browser, or their own generic spreadsheet application. The same goes for any activities common to all users or all organisations. At Chillisoft, which writes custom software for customers (and ourselves sometimes), we use many packages and platforms ourselves, some of which we pay licences for, and others which are free. In each of these cases, we are doing the same thing that thousands, or millions, of other business are doing – word processing, e-mails, writing code, source control, accounting, team chat, video calls, managing contacts, support ticketing and so on, and in these use cases there are large economies of scale going on, and the cost of building something custom is often not worth it.
Then there are the situations where your business's needs are similar, but not exactly the same as others. Sometimes these differences can be modelled into packages – for example, accounting packages allow you to construct different charts of accounts, enabling the same package to be used against different accounting policies. In other cases, there's no package that allows this modelling within the package. In this case, companies often try to implement packages that are sold as customisable. CRM packages are a good example. In this case, the vendor sells them as packaged software with customisations, or implementation costs, but if your needs are specific then the implementation costs can get quite large, and those same customisations can pose an upgrade risk. If the customisations you need are too extensive, they may not even be possible, because the packages (and low-code platforms) don't allow the developers to create abstractions the same way that they can in custom development – and these abstractions are key to managing complexity, which enables more complex rules or edge cases to be incorporated.
It's important to weigh up the options carefully: highly customisable, enterprise-targeting systems (and low-code/no-code platforms) are usually also quite expensive per user, per month/year. This means to determine the economically cheaper choice, one should look at the initial customisation cost, the customisation feasibility/risk and ongoing licensing costs, and do a financial analysis to weigh this up against the development cost of building custom and operating, supporting and maintaining that custom build over time, and the risks in doing this. There are still many cases where the latter is actually the better financial decision.
Custom builds are sometimes perceived as riskier, and this risk is quite difficult to quantify in the above financial analysis. However, the risks can be mitigated by applying an iterative/incremental approach with a development partner that has a track record of prior projects.
The final case is where custom is the only real option – this is the case where your organisation is trying to sell its own software as a service to others, or your use case is so specific that there is nothing like it that you can purchase. This one speaks for itself; in this case, the only question is how you go about creating the custom software.
There are two main options to create bespoke software:
- Insourcing – hiring a development team or utilising existing internal skills.
- Outsourcing – engaging with a vendor to build the software.
Insourcing is an option if you already have substantial development capability. If you don't have this, we recommend you bring in a highly experienced technical leader you trust, or appoint an external consultancy to provide that input. Without doing this, your risks are higher: we witness quite regularly the approach taken, where a company will ask an intern or student to write a business-critical system for them as this is cheaper than a professional studio or consultancy. However, incidents of systems being hacked, or taken down by bad actors, or data being breached are increasing, which is making the liability risk of operating a system higher than ever. Because of this risk, if you insource, it is still important to bring in advisors or risk assessors to ensure your system is safe for you and for your users.
When outsourcing, there are again many options. The model we've found to work the best is to allocate a team with all the needed skills, and then for the customer product champion and the development team to work as closely and collaboratively as possible, as iteratively as possible. Kent Beck's Extreme Programming is the original model for this; while there are cases where other models work just as well, this approach tends to be the one that works the best for most cases, in our experience. The highly collaborative, iterative methodology allows the customer and development team to continually align with one another, reducing the chance of large discrepancies between expectations and reality, while shorter to production delivery cycles ensure that what is being built is actually effective for users and for the business and minimise the cost of delay.
Whether insourcing or outsourcing, custom software development should be done with as much rigour in methods as is possible. These methods include:
- Continuous integration, continuous deployment and continuous delivery.
- Large-scale test automation and test-driven development.
- Continuous code reviews (necessary to prevent code entropy).
- Well-thought-out architectural patterns that are fit-for-purpose.
- Minimising work-in-progress and reducing batch size and cycle time.
- Incorporating observability in all areas through telemetry.
- A mindset of continuous improvement.
A good overview of these methods can be found in Dave Farley's Modern Software Engineering: Doing What Works to Build Better Software Faster, and a clear indication from research that companies that are practising them have a better chance of succeeding can be found in Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Nicole Forsgren, Jez Humble and Gene Kim.
Not all the above methods and practices would be appropriate to all custom builds – they should be selected based on your needs and environment. What is important is that the appropriate methods are chosen to maximise the project's goals, especially the economic goals. And, first and foremost, one should have it clear in one's mind what those economic goals are.
For example, when doing an MVP, you may drop test automation and you may simplify your architecture or choose a rapid prototyping tool (or extensive AI augmentation) – this is because in this phase you may be looking more for product-market fit and may need to be able to change tack very quickly and may throw out everything and restart in another direction. If, however, you are building a core business tool that is expected to have a long lifetime, you would make choices appropriate to that scenario (potentially eschewing or severely limiting AI augmentation, a topic for another day). The key is to select your strategy depending on the economics: a long-lived business tool is going to have completely different economics to something expected to be short-lived, or experimental, and therefore different options should be chosen.
While custom-building software can be a large undertaking, it can provide massive payoff. For many of our customers, their custom software has enabled exponential growth, and for others it has been able to drastically cut costs. And while it can be risky, there are many ways to mitigate that risk, including growing software iteratively and otherwise applying the lessons the industry has learned in the past 80+ years.
Finally, what has remained true for decades is still the case: without custom software, you are constrained by what your vendors can provide, and beholden to their upgrade paths and success/failure. With custom-built software, the power is in your hands to take your business into new territory.
If you're looking for a professional custom software development services team that puts your company's needs front and centre and seeks to collaborate for the long term, contact Chillisoft. For the testimony of a company that has been through this journey, see the recent interview published on ITWeb, with many thanks to De Heus SA and to Sonali Naidoo for being willing to share your experiences.
Share