Software strategy · 4 min read
Custom Software or an Existing Tool?
Compare a configured product, an integration, and a custom build using the same onboarding task. Test exceptions, costs, and migration requirements.
A shared onboarding spreadsheet has become difficult to manage. Sales adds customers, operations chases missing information, finance checks the terms, and a manager approves activation. The team is considering an off-the-shelf platform and a custom application.
Before comparing either, follow one customer through the process. The delay may come from copying records between systems, or from nobody knowing who can approve a change. A new platform may help with copying records, but the team still has to settle who can approve them.
Write down what the replacement must do
Use an actual completed request and an awkward one. Record who starts the work, which fields they need, who approves it, and where the final record belongs. Include what happens when a customer changes their legal entity halfway through review.
Separate requirements from habits. Finance may need to approve commercial terms; that approval does not have to live in the same colored column as it does today. A history of payment-instruction changes may be essential. Recreating every spreadsheet tab probably is not.
Write a test for each essential requirement. Can operations update onboarding details without seeing financial information? Does the CRM connection carry the exact fields you need? What happens if that connection fails halfway through an update?
Include the integration option
| Approach | When to consider it | What you will maintain |
|---|---|---|
| Configure an existing product | Its rules fit the process with acceptable compromises | Configuration, access, and the vendor relationship |
| Extend an existing product | Most of the process fits, but a connection or interface is missing | The extension and compatibility with future vendor changes |
| Build an application | Your requirements justify owning the software | Code, hosting, security updates, backups, and support |
Keep the current process in the comparison. A spreadsheet may still be adequate for the volume of work, especially if a clearer approval rule resolves the main complaint.
An existing product with a small integration is often worth testing before commissioning a replacement. It may cover the difficult part without making your team responsible for an entire application.
Bring your exceptions to the trial
Ask each candidate to handle the same records. Include a duplicate request, missing information, a rejected approval, and a staff member changing roles. Try exporting a complete customer record with its history.
Watch what requires an administrator or a workaround. In the onboarding example, a legal-entity change could affect the contract, finance approval, and CRM record. Find out whether staff can correct it themselves and whether the previous values remain available.
A workaround can be acceptable. Its frequency matters: ten minutes once a quarter is different from ten minutes on every customer.
Count the costs after launch
For purchased software, include configuration, migration, integrations, training, and the subscription tiers your requirements actually need. For a custom build, include hosting, updates, testing, backups, and future development. Both need support and someone to resolve bad records.
Estimate a low-volume and a high-volume year. Check how user count, record count, or automated actions affect pricing. Ask what it takes to leave: whether exports are usable, whether you retain access to your records, and whether another engineer could maintain the custom parts.
Time savings deserve the same scrutiny. Estimate how many requests will use the new process and how much review each still needs. Record uncertain assumptions rather than converting them into a precise return-on-investment claim.
Evaluate AI at the step where it would help
The onboarding application might benefit from a model that reads an incoming request and suggests a category. The rest may be ordinary forms, approval rules, and database updates. An existing platform may already handle that combination.
Test the classification with actual examples and measure the corrections it needs. If the decision follows explicit rules, those rules may be simpler to implement directly. Anthropic's guidance on workflows and agents discusses when a fixed sequence is sufficient.
Test the requirement most likely to rule an option out
If restricted access is essential, test the permission model first. If the project depends on an old accounting system, test its supported data connection. Run those checks before spending time on the interface.
For an existing product, use a configured trial with representative records. For custom software, build enough of the difficult part to try it. Mark simulated behavior so it does not get mistaken for a working integration.
Write down what would make you stop. An unavailable source interface or a review burden that consumes the expected time savings may change the decision.
Before choosing, plan the migration: which records move, which system is authoritative, and how users report problems. A gradual replacement may let you test one part before retiring the old process. Martin Fowler's Strangler Fig pattern describes that approach.
Record the choice, trial results, remaining risks, and the person responsible for the next step. If you want help assessing or building the replacement, see our internal software service.
The onboarding example is fictional. References were checked September 8, 2026.