In this article
Compare one complete working day
Suppose a maintenance company needs planning software. A vendor demonstrates a polished calendar; a custom proposal promises the exact workflow. Compare both on a real day: an urgent job arrives, a technician is absent, a customer changes the address and a completed intervention needs an invoice. Use the same scenario and data for each option.
Record workarounds as work, not as footnotes. Exporting a spreadsheet twice a day, re-entering customer details and manually reconciling invoices all create an operating cost. Equally, a custom build has to deliver ordinary capabilities such as permissions and administration that the vendor may already provide. The right comparison is the complete process, including its inconvenient edges.
Three ways to own the solution
Compare the full lifecycle, including integration and exit.
Buy
Standard capability. Check fit, vendor constraints and data export.
Build
Specific business behaviour. Fund delivery, maintenance and evolution.
Combine
Use a standard foundation and own the differentiating integration.
Separate commodity capability from operating advantage
Buy when the process is standard, the vendor model is acceptable and custom behaviour would not create a durable advantage. Building commodity authentication, invoicing or document storage usually creates ownership without differentiation.
Build when the workflow encodes how the company competes, when existing products force damaging workarounds, or when data, integration and control requirements cannot be met safely. Most decisions end as a deliberate hybrid.
Compare full ownership, not licence versus development
For a purchased product, include configuration, migration, integration, user administration, price growth, vendor changes and exit. For custom software, include discovery, delivery, security, operations, support, evolution and the internal decisions it consumes.
Model several realistic scenarios: normal growth, a critical integration change, vendor outage, data export and replacement. A cheaper first year can still create the most expensive constraint.
Write an exit-aware decision record
Record the decision owner, mandatory capabilities, accepted gaps, data ownership, integration boundary, security conditions and triggers for review. A trial is useful only when it tests the riskiest assumptions with representative data and users.
Preserve an exit path from day one: documented exports, stable identifiers, integration contracts and ownership of business rules. Avoid copying the vendor model so deeply that replacement becomes a rewrite of the company process.
Make a three-year model that can be challenged
For a chosen planning horizon, separate one-time migration and configuration from recurring licences, integrations, support and changes. Include the number of users and expected growth as explicit assumptions. For custom software, include maintenance capacity and the cost of replacing the people who know the system. Do not compare a vendor’s annual subscription with only the first development invoice.
Run a sensitivity review rather than trusting one total. What if user count doubles, the vendor changes an API, or the internal team loses its maintainer? Which assumption changes the decision? A slightly higher initial cost can be reasonable if it reduces a critical dependency, but that benefit should be stated and tested rather than hidden behind “strategic control”.
Test the exit before signing off
Ask for an export of a realistic sample, including attachments, relationships and historical statuses. Can another system reconstruct a usable customer record from it? Check how identity, integrations and contract termination affect access to that data. A downloadable CSV alone does not establish that migration will be straightforward.
A hybrid can work well: buy standard scheduling and build the distinctive intervention workflow around supported interfaces. Define which system owns each field so two applications do not fight over updates. End the comparison with a decision record, remaining uncertainties and a small acceptance trial. A procurement decision becomes much easier to defend when its essential assumptions have been exercised by actual users.
FAQ / DECISIONS
Frequently asked questions
Is custom software always more flexible?+
Only when the organisation funds ownership and evolution. Unmaintained custom software can be less adaptable than a well-chosen product with stable integration boundaries.