Decide whether to buy, configure, connect, or build.
Custom software is not automatically the serious option. If a maintained product fits the workflow and its limitations are acceptable, buy it. If the product is close, configure it. If the tools already work but information stops between them, connect them. Build only when the missing workflow is important, repeatable, and specific enough to own.
| Choice | Use it when | Hidden cost to check |
|---|---|---|
| Buy | The workflow is common and a credible product fits most requirements | Seats, migration, contract term, exports, and process change |
| Configure | The current platform has the fields, rules, and permissions needed | Complex customization that breaks on updates |
| Connect | Each tool does its job but staff re-enter data or chase status | Identity matching, API limits, failed sync recovery |
| Build | The workflow is differentiating or no product handles the real constraints | Ownership, support, security, change management, and maintenance |
The answer can be a combination. A custom intake layer may feed an existing CRM and accounting product. The smallest owned component is often more durable than replacing every system around it.
Price the current friction before pricing software.
Count the people who touch the process, minutes per touch, monthly volume, corrections, delays, and work that never completes. Include waiting and rework, not only typing time. Then identify what the first release can realistically remove or prevent.
Do not claim every saved minute becomes cash. Some savings create capacity, faster response, or fewer interruptions rather than immediate payroll reduction. State the assumption plainly. A useful business case may be "the same coordinator can handle growth without a second spreadsheet" or "the owner gets a trusted daily exception list before making scheduling decisions."
Walk-away test: If the value depends on automating a process nobody follows, rebuilding all historical data, or predicting revenue from vague efficiency, fix the process definition first.
A custom build needs operational boundaries.
Write the trigger, users, source systems, authoritative records, permissions, status model, exceptions, outputs, and support owner. Decide what happens when an integration is unavailable, a record cannot be matched, a user enters conflicting data, or a rule changes. Recovery is part of the product.
Keep client ownership concrete: source repository, deployment access, credentials under the client's control, data export, documentation, and a handoff path. A custom tool should reduce lock-in, not move it from a software vendor to a developer.
Build one working vertical slice first.
- Choose one frequent work item and follow it through the current process.
- Define the outcome and evidence that proves completion.
- Decide what existing software remains and where integration is enough.
- Build the smallest path from trigger to completed record, including one realistic exception.
- Run it with actual users and real data alongside the current process.
- Compare outputs, fix reconciliation, and document ownership.
- Add the next branch only when the first path is trusted.
For an Ottawa-area contractor, manufacturer, logistics company, or professional office, that slice might be quote-to-follow-up, work-order-to-invoice, document-to-ready-file, or source-data-to-owner-report. The geography helps with observation, staff training, and support. The decision to build should still rest on process fit and economics.