If you're building workarounds, you've outgrown your software

As long as a standard package follows your way of working, there is little reason to touch it. It only gets interesting when the software starts steering the operation instead of following it. In practice, that moment announces itself quite recognisably.

The first signal is the workarounds. Employees keep lists next to the package, export to spreadsheets to get something done or develop their own system of folders and copies. Creative solutions like these show that the package can no longer handle the way of working, because nobody builds workarounds around software that suffices.

The second signal is double work. The same data gets entered into two or three systems, and with every change someone has to remember to update it everywhere. That costs time, but the real risk is quieter: sooner or later the systems drift apart and nobody knows which version is right.

The third signal is the least visible one: the package cannot connect. Modern software opens up an integration layer through which other systems can read and write data. Older packages lack that layer, leaving little to automate. To find out how your package scores, you only have to ask the vendor one question: does this system have a modern API?

The question that follows is whether custom work is worth the investment. In my experience a custom system earns itself back. It is built around how your business works, contains only what you need and has no licence costs per user. Where many packages invoice per employee every month, the running cost of your own system stays limited to hosting and maintenance, however many people work with it. Automating or connecting to artificial intelligence is possible as soon as your business needs it, and a system can grow in phases along the way.

That does not mean every package has to go straight away. An interim solution sometimes makes sense: a flexible working tool like Notion can bridge a period, and for office communication a tool like Slack works fine. We look at those choices in the first phase of a project, together with the software you already have.

If you recognise the workarounds or the double work in your own operation, it is worth having it looked at. That first conversation is free of obligation and often says enough.