Is home-grown software worth it?
Unless it’s your core business, it is never a good idea to build your own digital product.
Commercial fishing company looking for an ERP? Buy one and get someone to integrate it for you. Healthcare insurer needing a new client dashboard? Get an Epic consultant to configure it.
Don’t do it
What seems like a money-saving move turns out to be much more costly to support, customize and update. At this stage, companies usually start to cut corners to economize. The product becomes a burden to use for the staff until someone has enough courage to mercy kill it.
You will inevitably end up in a situation where it’s impossible to do anything without a good amount of tribal knowledge: if you need to change a line on an invoice, you have to create another copy of a product with a different price and name it something like “!!!DO NOT USE” so another unwitting manager doesn’t sell it to a customer. I’ve heard stories of staff quitting because it was so frustrating to use their home-grown system. A pretty grim picture, isn’t it?
It’s a mistake to think that it’s enough to build the functionality you need and set the system loose. Software requires upkeep (security updates, minor modifications, update requests after external APIs changed) and thus a team to service it.
In case you need more convincing, run a quick financial analysis by comparing the costs of development, support, changes, security updates and liabilities from downtime or security breaches on your legacy software against licensing and professional services fees from a manufacturer. It will always come out one way, and that’s because manufacturers have a massive advantage you don’t — economies of scale.
That’s why it’s a good idea to purchase software from a company that has the infrastructure for it.
The exception
There’s one exception to this rule. The investment is worth it if you can make the product work as a separate business: a business with its own goals, financial flows and team. It’s a radical statement, but it’s the only way—a software like that has to live its own life.
As in any business, a product requires financial analysis: is the initial investment and ongoing cost worth the cost savings from improved operational efficiency? Is there an opportunity to commercialize?
Then, there’s the team. As products grow, even minor changes will become more costly because interdependency of its parts make it more complicated. The most persistent mistake I see is when developers add minor features on the fly, which reduces usability, architectural integrity and security of the entire system. The correct way to add new functionality is to go through the architect, who will evaluate the changes on all of these factors and then naturally incorporate it. That’s why the engineering team has to have at least one dev as an architect, a QA engineer, and a project manager. If you’ve ever wondered why Facebook needs thousands of engineers for a social posting app — that’s why.
Same thinking applies if you are already stuck managing a legacy product: turn it into a business. If it’s not viable as one, it makes sense to buy something off the shelf.
Never build your own software to save money, it just doesn’t work as a tactic. But if you have a vision to spin such a system off into a separate business and maybe even commercialize it: that’s something I definitely want to hear about.