Start with the workflow, not the category
Teams often ask whether they should buy software or build it. That question is too broad until they name the work that needs to improve. A CRM, ERP, scheduling system, BI tool, automation platform, or custom application may all be reasonable choices depending on the specific handoff, decision, and exception the team is trying to control.
Direct answer: Buy when a product covers the important workflow without forcing costly workarounds. Build when the workflow is a material part of how the business operates and standard tools leave staff with repeated manual work, unreliable data, or a risk the business must control.
The objective is not to own more code. It is to make an important process more dependable at a justified cost.
Separate common work from distinctive work
Many operations have both. Accounting, email, video meetings, payroll, and standard CRM functions are often better served by established products. The differentiating or complex part may be the way a company routes an order, validates documents, schedules field work, applies its business rules, or gives a team a single operational view.
| Question | What it reveals |
|---|---|
| Is this workflow common across our industry? | A mature product may already solve it well |
| Does the workflow create revenue, cost, or service risk? | It may need more than a generic workaround |
| How many staff steps happen outside the tool? | Manual reconciliation may be the real cost |
| Can configuration express the necessary business rule? | If not, extensions may become fragile |
| What happens when data is missing or a sync fails? | The answer shows the need for a controlled exception path |
Do not call a workflow unique simply because it is inconvenient. First simplify the process and confirm that the difference is real and valuable.
Compare total operating cost
License price is only one part of the decision.
| Cost area | Off-the-shelf tool | Custom software |
|---|---|---|
| Initial expense | Subscription setup, configuration, training, and possible implementation partner fees | Discovery, design, engineering, QA, launch, and handoff |
| Recurring expense | Per-user, usage, add-on, support, and price-change exposure | Hosting, third-party services, maintenance, support, and planned enhancements |
| Integration cost | Connectors may be quick, but limits can create workarounds | Integration can match the workflow, but must be monitored and maintained |
| Manual work | Often remains around tool gaps and exports | Can be reduced for the scoped workflow, but only if the process is well defined |
| Change control | Vendor roadmap and configuration limits | Company can prioritize changes, with responsibility for funding and operating them |
| Exit cost | Data exports, migration, parallel operation, and retraining | Data exports, documentation, migration, and a qualified replacement maintainer |
Use actual evidence where possible: hours spent rekeying data, error correction, missed service targets, subscription growth, failed handoffs, and delay in making a needed change. A generic five-year estimate is less useful than a clear model of one costly workflow.
Put both options on the same cost sheet
Use the same period, volume, and labor assumptions for both options. Keep cash costs separate from staff capacity that could be used elsewhere.
For illustration only, consider a three-year comparison for a services company’s job-status workflow:
| Cost over 36 months | Configure a product | Build a narrow tool |
|---|---|---|
| Setup or build, including migration and training | $6,000 | $30,000 |
| Monthly fees, hosting, and support | $500 × 36 = $18,000 | $300 × 36 = $10,800 |
| Remaining manual work at $30/hour | 20 hours/month × 36 = $21,600 | 5 hours/month × 36 = $5,400 |
| Combined cash and staff-capacity cost | $45,600 | $46,200 |
These invented inputs demonstrate the method; they are not Somnio quotes or market averages. Custom costs slightly more in this example, even though it releases more staff time. Add quoted exit costs, expected changes, and any outage costs before deciding. The result can reverse when volume or support needs change, so recheck the calculation if those assumptions move.
Make integrations and exceptions part of the decision
A stack of good products can still create a poor operating process if staff must copy data among them. Before buying or building, name the source of truth for the important records and the person who resolves a failed handoff.
In a services business, the scheduling tool might own appointment times while accounting owns paid status. If staff copy both through a spreadsheet, trace one job from booking to payment. State which system wins when values disagree, how a duplicate update is prevented, and who gets the failed-sync alert. Keeping both existing products and replacing that spreadsheet handoff may solve the problem without a new platform.
The business software integration checklist covers field mapping, validation, duplicates, retries, monitoring, and reconciliation. These are required whether a connection uses an iPaaS product or custom code.
Use a staged decision instead of a big commitment
| First move | Best when |
|---|---|
| Improve the existing process | Input quality or ownership is unclear |
| Configure an existing product | The required workflow is standard and supported |
| Add one focused integration | Good systems exist but a repeated handoff is broken |
| Build a narrow internal tool | Staff need a controlled queue, role-specific action, or a unique rule |
| Replace a broader platform | Evidence shows the current foundation cannot meet a critical requirement |
Start with a measurable outcome. A new operational tool might aim to reduce incomplete requests, give every exception an owner, or remove a repeated export-and-import cycle. A tool that has no defined operating question is likely to become another place for staff to update data.
Do not create five small tools with five unowned support queues. Record who maintains each tool, which records it owns, and when it should be retired or combined with another system.
Consider ownership without overstating it
Vendor lock-in is not limited to custom software. A SaaS product can create operational dependence through data formats, pricing changes, access limits, or a difficult migration. Custom software also has dependencies: hosting, libraries, APIs, skilled support, and documented operating knowledge.
The practical question is what must stay under company control. For a custom build, that commonly includes repository access, cloud accounts, domains, service credentials, deployment instructions, architecture decisions, and a way for another qualified team to maintain the system. Somnio’s fixed-price and IP ownership policy describes its public approach; the signed agreement controls final terms.
A real workflow can change the economics
Somnio’s published meal-delivery routing case study describes a company that replaced a costly routing dependency with a custom layer around lower-cost mapping services. The published result was a reduction in monthly routing costs from $2,500 to $300 for that client. The right lesson is not that every team should replace SaaS. It is that a custom boundary may be worthwhile when the cost structure and operating needs of a high-volume workflow no longer fit a vendor product.
That is a $2,200 monthly reduction in reported routing costs, not net project return. Count the build investment and any additional operating costs before estimating payback. Divide initial investment by a positive monthly net benefit; if the benefit is only released staff capacity, do not describe it as cash payback.
For a process with disconnected systems, start by mapping the records and exceptions. The operational dashboard design guide explains how to focus the first view on a real decision rather than adding charts to a fragmented workflow.
Roll out without stopping operations
In the routing case study, the new layer mirrored the existing API contract and its results were compared against the old system before production traffic moved. The published implementation took three months; that is evidence for this project, not a schedule for your build.
For your rollout, pilot with one team and compare outputs without allowing both systems to create the same live transaction. Reconcile records before cutover, train a primary and backup owner, and agree on the fallback and support contact. Budget staff time for the pilot and training. The migration is not complete merely because the new screen loads.
Bottom line
Off-the-shelf software wins when it supports the important work with acceptable cost and control. Custom software wins when a valuable workflow cannot be managed safely or economically through configuration and manual workarounds. Measure the complete operating path, start with a narrow outcome, and preserve control of the records and decisions that matter most.
Somnio’s architecture consulting and AI automation discovery can help a team compare product configuration, integration, and a focused custom build before it commits to a broad software program.
Start with the published $2,000, one-week workflow audit when you need to assess one process. Use architecture consulting when the existing system’s reliability or technical limits need closer review. Ongoing support needs its own scope; source-code ownership does not mean maintenance is free.
