Before writing code, ask whether you need to. These six questions help, and your honest yes or no matters more than any quote.
The six questions
- Is the process an advantage or a common function? Invoicing, mail, accounting: mature products exist. A way of working that sets you apart rarely fits a standard product.
- How much must you adapt the product? If most of the work is configuring exceptions, you are already building custom software, only inside someone else’s limits.
- Which integrations are needed? A system that must talk to ERP, warehouse or machines can be simpler to build around APIs than to force into a closed product.
- Where is the data and who controls it? Check export, open formats and what happens if the vendor changes terms. For personal data, consider data protection by design from the start (GDPR, art. 25).
- What does it cost over time? Compare licences, customisation and fees with development, hosting and maintenance. The initial cost is the most visible part and often the least important.
- Who will maintain it? Custom software without tests, documentation and code in your own repository depends on whoever wrote it. That is the main risk.
A prudent way to proceed
- Start from the most frequent case and ship a minimal version, not the whole system.
- Require automated tests, repeatable releases and code you own from day one.
- Keep the standard parts on ready-made products and build only what sets you apart.
- Set an exit criterion: how to migrate if a product or supplier stops fitting.
What is not verified
This note is a decision guide with no market data or costs: no figures are given because they depend on the case. For data protection see the official text of Regulation (EU) 2016/679.
To assess your case, see Software engineering or ask for a second opinion.