Meta Bytes' CTO and biggest tech nerd (?) Oskar took a moment to write down what to think about when building a custom-made software system.
This might sound obvious but trust us, this is key. Who knows the requirements for the system? Who makes the decisions on what features should be included or not? Who is going to own the communication between your business units as the development gets underway? All of these and more need to be defined to make sure your software development journey is as smooth as possible.
Equally important is to ensure that you have the right stakeholders involved and that you have their buy-in. There’s nothing like developing a system for order management without speaking to, ahem, the people who currently manage your orders.
What is it you want to achieve with your system? What challenge is it that you want to solve? Crucially, what is it you want to reflect back on once the system is live (whilst you’re sipping champagne and celebrating) and think “Wow, I don’t need to deal with that problem anymore”? Defining this, and continually returning to it throughout the development journey, will ensure that you get to where you want to be. It’s particularly good if you can define what you want to achieve in a measurable way. For instance, once I’ve launched this system, I’ll be able to spend 20% of my time on really valuable work, rather than the time I was spending dealing with a recurring issue.
This is all about identifying what you want your system to do and discovering how you can get there on time and within budget. When looking at what your system can do, it’s really important to remember to balance value and business impact vs effort and cost. It’s really easy to get bogged down in edge cases or the last 10% and spend all your money and effort solving those. Instead, focus on the primary workflow or cases that you are trying to solve. You’ll often find that you can solve almost everything you need at a reasonable cost, whereas solving absolutely everything will blow your budget, your time and in turn, the business impact of your system.
This means realizing that you won’t have everything in your system from your first go-live – and that’s okay! To get you the best value for money, the development of your system should be done using agile methodology, which is centered around developing iteratively and delivering incrementally, rather than all at once. Using short feedback loops, agile ways of working make sure that the design of your system is adapted quickly to your users’ feedback and your business environment. Think of it this way - this means that if you thought you needed an eight seater sofa but in fact you only needed a simple kitchen chair, the design is adapted before you’ve paid for the sofa cushions.
Here, it’s basically about always working with the assumption that you won’t be finished when you think you will be finished. And no, we don’t mean that the project will be delayed - we mean that by the time the first version of your system has been launched, you’re bound to have discovered loads of new features and uses that you hadn’t thought of when you started.
The more your new system can do, the better. What’s key is ensuring that the design of the system doesn’t box itself into not being able to cater for these new features and uses in the future – in short, making sure it’s flexible and scaleable. We always use best practice design principles to ensure future flexibility and opportunities, so we’ll make sure you’ve got this covered.
Not sure if your business should go custom? Then have a look at another Oskar's article Five signs that you should consider custom software for your business.