In our last post we promised a simple example of the thought/assessment process around whether one should buy software or build software.
Importantly this is around software and not web design (oft confused). Web design is relatively simple when compared to software design. Web design is the process of creating a visual and (relatively) static representation of information/content whereas software involves ‘behind the scenes’ processes that are (more often than not) not seen by individuals as the heavy lifting is done in the background. A good example is Google’s search interface. Super simple on the skin (and relatively easy therefore to web design) but massively powerful behind the scenes to make it work. You see the search layer, you don’t see the processing.
It’s not purely a financial cost decision but also involves time and control. Basically building your own means you will need to wait for it to be finished, you’ll soak up a lot of management time, you’ll need a refresh in less than four years and you’ll need to cover all the ongoing maintenance costs. All this assumes you undertake no development after delivery. Platform services will provide these features as part of the service – that’s what their business is – constantly pushing the R&D limits to be the better than others in the sector.
Fundamentally it’s about deciding whether to stick to what you are good at or tinker. If you are good at publishing music why would you build houses? or run servers? or develop software?
Below we list some typical components that go into a lightweight development project, for example a system that may total up royalty payments across a number of offices, providing reports to artists and publishers through differing access levels while providing a CMS (Content Management System) to control content on the site that your clients will see. We’re not even going to broach financial cost in this example, just time cost. All time costs are detailed in ‘man hours’ e.g. four months is one person for four months or two people for two months.
1. Planning – The product needs to be designed and commercial requirements need to be fulfilled. This takes a significant chunk out of the stakeholders time in the business along with someone to write the resulting specifications. The double whammy is that any time the management spend on this they are not spending doing their day job. Call it working out your route map before undertaking the journey. A properly specified plan is needed to build a properly specified system. Even for our team, who know how to do these things, this takes significant time, and we do this day in day out. Call it a couple of weeks.
2. The actual development – This is the only bit that most people think of when considering the overall question, so lets keep it simple. It might be 3-4 months depending on the complexity of the CMS or complete green field development. This is the ‘build’. However there’s a whole lot more:
3. Design – you need some design treatment on your site. Lets add in another month here. If it looks clunky/poor, people are going to think it looks clunky/poor. You wouldn’t want a pig-ugly Mercedes or a BMW where the door handles came from a Ford.
4. UI/UX – What’s UI/UX (User Interface/User Experience)? You need to make sure your system is usable and logical i.e. you click a button and the right thing happens and the user ends-up where they expect to be! Sounds simple but actually it is an art. The art of making software behave in the way in which people behave in the real world. The customers looking for reports need to find what they need quickly and easily without ringing you up the whole time. That’s another few weeks of work.
5. Testing – Software always needs to be tested. Someone has to do this. Another week or two. The worst thing to do is to launch your product, high five your colleagues and then watch it fail as someone does something unexpected and/or too many people do too many unexpected things!
6. Project management – someone has to pull this together. Decisions have to made on a daily basis on features and data to make sure the right thing happens at the right time and product actually does what is expected. Expect 20% or so on top of the number of days for all the above. It’s looking like a real mission now. But the softer costs need to added in.
7. Risk – This is difficult to be exact on but something will cause an issue along the way causing inevitable delays to the delivery. Put in a contingency to deal with this (10%?). You may also need some specialist skills somewhere. Also to be factored into risk is what happens if a key team member goes off ill or has an accident – it can take weeks to get someone else up to speed if they don’t have access to key team member.
8. Management time – Something like this needs a product owner in the business to make commercial decisions as they arise. Even if the planning was good there will be a host of small decisions to make, engineering is about making compromises to balance the technical and commercial requirements. This needs business input. Again, someone valuable in a music company is working on the software. We’ll add a week in here.
9. Ongoing costs – You then have to maintain it. This means keeping some sort of relationship with the developer going to add the odd feature in, fix the inevitable bugs that come up. If the original developer is no longer around then you need to find and train another. You also have to host this somewhere and pay for things like bandwidth and storage. Let’s call this a day a week for the foreseeable.
So what does that add up to….. we could have just said it in four words – “a lot of time”.
So if you can cope with this kind of workload alongside daily operations then you may think you should just go for it! However the last balancing factor is the cost equation. Even if you are capable of doing all of the above, can you buy something ready-made/developed for less than the actual cost for doing so. Even if you could write an encyclopaedia, would you do it if you could buy one for $100 rather than incurring $100,000 of cost in developing it? We suspect not, and therein is the rub. You should really only develop encyclopaedias if a) you want to sell encyclopaedias b) your encyclopaedic needs are entirely different to everyone else or c) you couldn’t give a monkeys about logic and you just want your own encyclopaedia at all costs.
Software companies make it work because they have a dedicated team doing all the tasks above. That team is producing software that is used across multiple clients, all of whom are therefore bearing parts of the cost and not the entirety. It is more efficient to develop for many than for one. The benefits are then shared.
