An internal-tool request often starts with a screen: a list of orders, an approval button, a weekly report. I start with the work behind it. Who needs to do what, which records do they need, and what happens if the tool is unavailable?
Then I compare three routes. Buy means configure an existing product around the task. Integrate means keep suitable tools and connect the missing handoff. Build means develop the part of the workflow that an existing product cannot reasonably provide. A project can contain all three, but each part needs a cost and an owner.
Which option fits the actual task?
I first check whether each option can complete the same workflow safely. A low-cost option that cannot enforce an essential rule is not a candidate. Cost comparisons come after that check.
Comparison table — scroll horizontally to see all columns
| Question | Buy | Integrate | Build |
|---|---|---|---|
| Where does the work happen? | In an existing product with configuration | In existing tools, with a defined handoff | In a new tool for the missing workflow |
| What must I verify? | Required roles, approval steps and usable exports | Access to each system, field ownership and recovery | Rules, permissions, acceptance tests and operation |
| What drives setup cost? | Configuration, migration and training | Mapping, implementation, failure handling and tests | Design, development, migration, tests and handover |
| What drives recurring cost? | Licences, usage and administration | Existing licences plus operating the connection | Hosting, dependencies, maintenance and administration |
| What must the exit cover? | Export, replacement configuration and retraining | Replacing the connection and checking both sides | Moving data and code, or replacing the tool |
GOV.UK’s technology guidance asks teams to understand existing systems and data, keep technology adaptable as their understanding of user needs changes, and minimise total cost of ownership. I use that as decision guidance here; it is written for government services.
For a handoff problem, the direct API integration situation is the closest route. If control of the hosting and operation is the requirement, read the self-hosted business stack situation. They are different reasons to commission work.
What belongs in a 12–24 month budget?
I count the work required to start, keep operating and eventually leave. Internal time has a cost even when it does not produce an invoice. I write down the assumptions so a different person can recalculate the comparison.
My working model is:
Total cost of ownership (TCO) for N months = initial work + N × monthly operating cost + exit allowance.
Initial work includes selection, configuration or development, integration, migration, acceptance checks and training. Monthly operating cost includes licences, hosting, usage, routine maintenance and staff handling. The exit allowance covers exporting, mapping, checking the replacement and retraining. It is reserved once in each comparison, not charged monthly; it may never be spent.
I also list costs that are uncertain: new requirements, a change in usage, contract renewal, an upstream change or a recovery task. For a real decision I would make a base case and a higher-cost case. I would not hide those uncertainties in a single precise total.
All amounts below are hypothetical USD budgeting inputs. They are not vendor prices, my rate card, estimates of market rates or past results. The initial sums include setup, training and any integration work. The monthly sums include licence or hosting allowances, maintenance and internal handling, as stated in each scenario. Taxes and financing are excluded. Usage stays constant; no savings, revenue gains or future price changes are assumed.
Hypothetical scenario 1: a standard approval queue
Suppose a team needs requests, one reviewer, approval history and an export. An existing product passes all four checks without custom code. Under these assumptions, buying wins because the workflow already fits.
The hypothetical inputs are:
- Buy: $600 initial work; $150/month for licences and $50/month for administration; $400 exit allowance.
- Integrate: $2,000 initial work; $100/month for existing tools and $150/month for connection maintenance and administration; $800 exit allowance.
- Build: $8,000 initial work; $50/month for hosting and $300/month for maintenance and administration; $1,000 exit allowance.
Comparison table — scroll horizontally to see all columns
| Option | TCO: 12 months | TCO: 24 months |
|---|---|---|
| Buy | $3,400 | $5,800 |
| Integrate | $5,800 | $8,800 |
| Build | $13,200 | $17,400 |
For example, buy at 24 months is $600 + 24 × $200 + $400 = $5,800. The result depends on the product passing the workflow checks. If a required approval rule is unavailable, I would revisit the shortlist rather than force the process into that product.
Hypothetical scenario 2: two tools, one broken handoff
Suppose orders and fulfilment already have suitable tools, but staff copy status between them. Both systems expose the required interface, and the team has agreed which system owns each field. Under these assumptions, integrating wins; replacing either tool adds work without solving a new requirement.
The hypothetical inputs are:
- Buy: $3,000 initial work to move to a replacement suite; $500/month for licences and $100/month for administration; $1,500 exit allowance.
- Integrate: $3,500 initial work; $150/month for existing licences and $150/month for maintenance and exception review; $800 exit allowance.
- Build: $10,000 initial work; $150/month for retained licences, $50/month for hosting and $350/month for maintenance and administration; $1,500 exit allowance.
Comparison table — scroll horizontally to see all columns
| Option | TCO: 12 months | TCO: 24 months |
|---|---|---|
| Buy | $11,700 | $18,900 |
| Integrate | $7,900 | $11,500 |
| Build | $18,100 | $24,700 |
Integrate at 24 months is $3,500 + 24 × $300 + $800 = $11,500. I would write the API integration brief before choosing the connection: fields, direction, cadence, duplicates and recovery.
If these orders also feed analytics, I agree a stable matching key. The transaction ID entry explains GA4’s purchase identifier, which Google says must be unique for each order. Order reconciliation shows how I check those purchases against the underlying orders. The fulfilment integration still needs its own agreed field mapping and acceptance tests.
Hypothetical scenario 3: a rule the available tools cannot enforce
Suppose a planning team needs allocation rules and a second-person approval before committing a change. In this hypothetical shortlist, the bought and integrated options require staff to enforce those rules manually. A custom build is the only candidate that meets the required workflow without that workaround.
The hypothetical inputs include the manual handling rather than treating it as free:
- Buy: $1,500 initial work; $250/month for licences and $1,250/month for administration and manual rule checks; $1,000 exit allowance.
- Integrate: $4,000 initial work; $200/month for licences, $200/month for connection maintenance and $600/month for manual rule checks; $1,500 exit allowance.
- Build: $12,000 initial work; $100/month for hosting and $350/month for maintenance and administration; $2,000 exit allowance.
Comparison table — scroll horizontally to see all columns
| Option | TCO: 12 months | TCO: 24 months |
|---|---|---|
| Buy, with manual rule checks | $20,500 | $38,500 |
| Integrate, with manual rule checks | $17,500 | $29,500 |
| Build | $19,400 | $24,800 |
Build at 24 months is $12,000 + 24 × $450 + $2,000 = $24,800. Integrating has the lower 12-month total, but does not pass the stated requirement. I would either fund the build, change that requirement explicitly, or keep the task manual for now. These figures do not prove that custom software becomes cheaper at a particular scale.
Who owns the data, and what does leaving cost?
I check both the agreement and an actual export. Control means being able to obtain usable records, understand their meaning and move the workflow. Having a download button or a code repository is only part of that check.
The GOV.UK guidance on cloud lock-in distinguishes commercial restrictions from technical dependence. It covers data access, portable formats, and the cost and time to exit hosting arrangements. It also recognises benefits from accepting some dependence. I apply that exit-planning question to the internal tool; I do not treat complete independence as a requirement for every small tool.
My checklist is practical: who controls the subscription, infrastructure and credentials; what rights the agreement gives you to data and custom code; whether attachments, history and relationships survive export; who can operate the replacement; and how long both systems must run while the result is checked. For a build, I add deployment instructions, backups, dependency licences and a recovery runbook.
How I verify this in real implementations
I would test the essential workflow before accepting a quote or a finished tool. These are proposed acceptance checks, not tests performed on a real product for this article. The result should be a written pass, fail or unknown for every requirement.
I use a small synthetic record set: a normal request, a rejected request, a duplicate, a failed handoff and a record that needs correction. I check permissions, history, recovery and export. A second person should be able to find a failure and follow the recovery instructions without asking the original developer.
For the budget, I ask for the actual billing unit and renewal terms, separate included support from new work, and name the person who reviews exceptions. If an input is unknown, I mark it unknown. I do not fill the gap with an invented average.
Common failure modes
The comparison fails when the options describe different jobs. I would check the following before trusting its totals.
- Comparing a licence with a complete implementation quote.
- Dropping existing subscriptions from the integration or build column.
- Counting staff review and recovery as free.
- Assuming custom code removes dependence on its hosting or developer.
- Budgeting an export without checking whether another system can use it.
- Choosing a cheap option that cannot enforce the required permission or approval rule.
Limitations and alternatives
These scenarios are a method for comparison, not a forecast. They assume fixed scope and monthly usage. They do not quantify business benefit, interruption losses or changing requirements. A decision still needs your constraints and current written quotes.
A manual process or a configured spreadsheet can be a sensible interim option while the rules settle. A narrow integration can be a reversible next step. If the decision includes an AI component, the agent or workflow automation guide addresses a separate question: which steps need model judgement and which need explicit rules.
I can scope the missing part under API integrations and workflow automation. Send the workflow, the systems and the constraint that matters most. That gives us something concrete to compare before choosing a tool or commissioning a build.
