Guide · Technical decisions
Custom software or an existing product?
First test whether an existing product solves the important workflow. Custom development makes sense when a decisive requirement remains unmet and you can maintain the solution. There is also a middle option: keep the product and build only the missing integration or feature.
Describe the work before comparing products
Prepare three cases: the normal journey, a frequent exception and an error that needs correction. Identify who enters data, who approves and who may view it. A feature list without a workflow makes almost any demo look sufficient.
Hypothetical example: a maintenance team needs to assign visits, attach photographs and close jobs offline. The decisive test is what happens when connectivity returns, not how many icons the dashboard offers.
Buy when the common workflow is already solved
If a product handles the important cases with reasonable configuration, test it before commissioning a replica. Check permissions, exports and limits on the plan you would buy, not just the demonstration environment. SaaS means software delivered as a service, usually by subscription; installed products and open-source options also belong in the comparison.
Ask the supplier to run your exception case, using the permissions and subscription tier you would actually have. A feature described as “supported” may require an extra module, a manual workaround or a different contract. Put those dependencies in the comparison.
Build the features existing software cannot provide
Custom development can fit when a workflow, customer experience or critical integration cannot be handled well by existing products. Define that difference precisely and the improvement you should be able to observe.
A small application connected to the current system may be enough. A missing progress view does not require rebuilding billing, scheduling and document management too.
Compare operating and exit costs
Include setup, migration, licences, integrations, support and likely changes over the same period. For custom software, add hosting, backups, updates and incident ownership.
Open-source software still needs maintenance and support. For either option, ask who restores a failed backup, changes a business rule and takes over if the current supplier leaves. Repository access without a working handover is not a maintenance plan.
Test export before committing
Create test data with relationships and attachments. Export it and check whether another tool can reconstruct the case. A contact CSV does not establish that you can recover permissions, history and documents.
For the maintenance-team example, export one job with its customer, assigned technician, photos and completion history. Check that each relationship survives. If the export loses attachments or stable identifiers, record the rebuilding work before accepting the product.
| Existing product | Custom development | |
|---|---|---|
| Offline job completion | Demonstrate it on the intended subscription plan. | Include local saving and synchronisation in the scope. |
| Unusual approval step | Check configuration before adding a workaround. | Specify who approves and how rejection returns the job. |
| Operating responsibility | Confirm support scope and what the team still owns. | Name the maintenance owner and handover requirements. |
| Exit test | Export a complete job with its relationships. | Provide an export and test restoring usable data. |
Record the decision and when to review it
Write down the choice, exclusions, maintenance owner and changes that would justify reconsideration. For example, buy now and add an integration if duplicate entry exceeds a threshold agreed by the team.
If you do not yet know whether the workflow works, test its most uncertain step before pricing the entire application. “Do not build yet” is a valid conclusion.
To define the next step, read what to validate with a demo or prototype.
Sources and further reading
Questions before we start
Is custom software always more expensive?
You cannot establish that without comparable scope and time periods. Compare implementation, use, support, changes and exit, not just a subscription against the initial build quote.
Can I keep my CRM and add custom features?
Often, if it provides a suitable integration route. Check supported operations, licences, permissions and limits before designing the addition.
Who should hold the code and accounts?
Agree repository access, licences, hosting accounts, documentation and handover in writing. Ownership and rights depend on the agreement; do not assume them.