Build, buy or integrate your business software?
Compare process changes, ready-made products and custom applications against ownership, workflow fit and total operating burden.
What does a business automation project really cost?
A useful automation removes work without moving the same burden into correction, monitoring or an expensive subscription. The comparison starts with the task you perform today, not the price of a model or an optimistic percentage saving.
Keep three options visible: improve the current process, use existing software, or commission a connected implementation. The most elaborate option does not automatically produce the best financial result.
| Approach | When it may fit | What to inspect |
|---|---|---|
| Simpler process | Repeated work has inconsistent inputs or unclear ownership. | Standardize the inputs and measure a normal operating period before adding software. |
| Existing software | A named product already handles the task and its exceptions. | Include licenses, setup, export limits, reviewer time and cancellation costs. |
| Connected implementation | Several systems, permissions or business rules must work together. | Include discovery, connectors, tests, operation, maintenance and handoff. |
Measure a complete case, not the best example
Count how many cases arrive in a normal month. Separate routine handling time from the extra minutes spent on exceptions. Include rework, duplicate entry, waiting for a reviewer and the work needed to correct a failed run. Waiting time and human effort are different measures; do not value every elapsed hour as paid labor.
An estimate is acceptable for an early decision when it is labeled as an estimate. Record its source and review date. Later, replace it with measured observations rather than silently improving the assumption.
- Cases per month, with a defined case boundary.
- Routine human minutes and exception frequency.
- Extra minutes per exception and the reviewer involved.
- Paid hourly cost and the portion of that cost actually avoidable.
- Unpaid setup and operating time, valued separately.
Separate cash, capacity and risk
If employees finish earlier but payroll remains unchanged, the released time is capacity, not a cash saving. Avoidable cash may exist when a real contractor bill, overtime charge or other paid cost is reduced. Use the actual avoidable portion rather than assuming every released minute becomes money in the bank.
Economic value can include capacity and unpaid owner time, but it must stay separate from cash flow. Revenue growth, error losses, tax effects and financing are not automatically implied by a labor model. Add them only to a separately supported business analysis.
- Compare net cash after setup over the chosen horizon.
- Inspect monthly flows during adoption, not only steady-state savings.
- Keep negative values and unrecovered setup costs visible.
- Treat alternative projects as alternatives; do not add their savings together.
Budget for the system after delivery
List platform charges, usage fees, paid support and the time needed to review results. Identify who notices a failed integration, who can repair it and how quickly the original manual process can resume. A cheap unattended workflow can become costly when its exceptions are invisible.
Phase budgets and setup estimates are different views of the same delivery. Do not add the same implementation labor twice. The project pack provides a starting scope; a written quote and the named product's terms define the actual purchase.
- A documented baseline and two comparable alternatives.
- A named acceptance owner and an exception-handling path.
- An agreed operating-cost boundary and support arrangement.
- Measured post-delivery results before claiming savings.
Working checks and planning tools
Use the free checks independently, buy a named product when it fits, or commission the part that needs connecting. An estimate is not a quote or a customer result.
More buyer guides
Choose local, cloud or hybrid AI for the actual workload
Compare data placement, hardware, model quality, usage costs and fallback behavior before choosing a deployment architecture.
Design document automation around exceptions and evidence
Turn invoices, forms and operational documents into usable records while preserving provenance, review and correction.
Move an AI pilot into a useful production workflow
Define observable acceptance, evaluation, permissions, exception handling and operating ownership without turning a prototype into an unsupported promise.
Plan an API or MCP integration with clear ownership
Define data contracts, permissions, retry behavior, evidence and maintenance for a useful business integration.