When custom software is worth the work
A specific process can justify custom software, but configuration and integration may solve the problem. Compare alternatives before commissioning a build.
A company copies information between three spreadsheets and calls it a missing-system problem. It might be. It could also be unclear fields, a missing integration or a process nobody agreed to follow. Building software before finding the cause risks turning confusion into a permanent screen.
Custom software makes sense when an important operational rule cannot be handled acceptably by available options. The criterion is not wanting something exclusive. It is the gap between the required process and what existing tools can do.
Describe a real case from beginning to end
Choose a frequent task and record inputs, decisions, owners and outcomes. In a hypothetical maintenance operation, a request arrives by message, someone sets the priority, a technician performs the work and another person approves the charge. Observe where information disappears and which delay results.
Include exceptions: missing parts, return visits, reassignment and cancellation. A prototype showing only the ideal route can look simple while leaving most of the work outside the project.
The UK government’s Technology Code of Practice sets criteria for designing, building and buying technology. Its focus on needs and lifecycle offers a useful reference for comparison.
Compare three options against the same task
| Option | What needs demonstrating |
|---|---|
| Configure | The existing product completes the workflow with practical adjustments. |
| Integrate | Tools exchange information without repeated manual work. |
| Build | A new application handles the missing rule and has a maintenance plan. |
Request a demonstration using example data from your routine. Compare the complete journey rather than feature lists. A tool may advertise approval management yet fail to handle how your organization replaces an absent approver.
The budget must cover life after delivery
Include data import, training, access management, hosting, updates, monitoring and support. Record who decides on changes and how they will be prioritized. The initial price does not describe the effort required to keep an application in use.
Before commissioning, clarify source-code delivery, documentation, access, dependencies, usage terms and continuity with another team. Do not assume “custom” settles these matters automatically. They need to be written down and understood by both parties.
Start with a part you can verify
For the maintenance example, a first delivery could track requests, assignment and completion while keeping billing in the existing system. This allows comparison between the old and new routine without replacing everything at once.
Define observable checks: two people updating the same record, an unauthorized user attempting an export, an integration failure and recovery of a record. Validate with the people doing the work and document cases that still need manual action.
If the plan is to sell the product to several organizations, the discussion moves to SaaS and customer isolation. If AI assists the build, keep the delivery criteria described in the AI development lifecycle; a tool does not replace a defined process.
About the author
Tiago F SantiagoComments
No comments yet
Share a question or an experience related to the article.
Related articles
