An existing product promises a quick start. Custom software promises a closer fit. Both sound appealing until someone needs to process a real case, move existing data or change a workflow.
Start with examples from your own team's work. They keep the discussion focused on what the system needs to do, rather than on technology preferences or feature lists.
Show an ordinary task and an exception
Describe a normal case from start to finish. Add a harder situation: correcting an approved request, covering for an absent colleague or withdrawing a submission. Prepare sample data without sensitive information.
Ask the product supplier to demonstrate these tasks. For a custom build, discuss how they would work and what needs to be clarified before the team can price them.
Separate configuration from product changes
For each requirement, record whether it is available now, configurable, needs development or cannot be supported. Ask who maintains modifications and whether they will keep working after upgrades.
Custom software has dependencies too: libraries, external services and the team's knowledge. Commissioning code does not automatically resolve future development or handover to another supplier.
Compare the complete cost
Include setup, migration, integrations, recurring fees, improvements and the end of the relationship. For a licensed product, check what happens when user numbers increase. For a custom build, identify the work that continues after the initial release.
Use the three-year budget example with the same period and scope for both options. Avoid comparing a one-year subscription with a complete build and several years of support.
Finally, name the compromise. Which parts of your process would change to fit the product? Which differences are valuable enough to develop separately? If you cannot answer those questions, investigate the workflow further before deciding how to buy the software.
Every number in this article, plus thousands of other contracts, is in the database.
Open the database