Buy software or commission an AI integration?

You have a working client management system, a document store, and a team that still copies information between them. A new AI product promises to fix the handoff. An implementation partner proposes a custom integration. Both options might be reasonable, but they solve different ownership problems.

I would begin by naming the gap. Is the missing capability already available in a tool you use? Does the business need a connection between existing systems? Or does the process require behavior that no suitable product provides? Buying a new platform before answering those questions can turn one missing handoff into a migration project.

This is a decision guide for evaluating a specific workflow. The examples are hypothetical. They are not claims about software I have deployed for a client or savings a business has achieved.

Write down the smallest useful outcome

Take client onboarding in a professional services firm. A useful outcome could be: when an agreement is approved, prepare a project record with the correct client, owner, dates, and source document, then send it to a manager for review. That is narrower than replacing the firm's operations platform.

Write down the trigger, source information, permitted actions, human decisions, and completion evidence. Include an exception: the agreement names two different start dates, or the client already exists under another trading name. The solution has to handle that uncertainty without quietly choosing the wrong record.

Once the outcome is clear, you can ask each vendor to demonstrate the same thing. A product tour should not replace that test. Features that do not contribute to the chosen workflow should have little weight in the decision.

Check the software you already own

I would first inspect existing product capabilities and contract entitlements. A supported workflow feature may already cover the task. The right answer could be configuration, a permissions change, or a small extension. Verify current documentation and account access before assuming a feature is available.

Ask an administrator to distinguish an included capability from a paid add-on, a preview, or a feature available only under a different contract. Also check whether the feature can respect your actual access rules. A useful automation that requires broad access to every client record may be unsuitable.

This is discovery work with a clear stopping point. If the existing product cannot perform a required action or cannot expose enough evidence to operate safely, document the gap and move on. Do not spend weeks forcing a configuration to behave like a custom application.

Buy when the standard workflow is a good fit

An established product is a strong candidate when its supported process matches your needs and you can accept its operating model. In that case, the supplier owns a larger share of product maintenance. Your team still owns configuration, access, training, and the business decisions made through it.

I would ask for a trial using representative, sanitized inputs. Test the difficult handoff and the exception queue. Check how records are exported, how roles work, how changes are recorded, and what happens if you stop paying for the product.

The decision should include migration and adoption effort. A lower subscription invoice does not settle whether a new platform is less expensive overall. Microsoft explicitly includes building, buying, and extending in its AI cost evaluation framework. Microsoft's evaluation guidance

Extend when the gap sits between good systems

A custom integration is a strong candidate when the core applications are useful but their handoff is incomplete. For example, the document system may hold the approved agreement while the project system needs a structured record. A bounded integration can connect them without replacing either.

I would keep each application's authority clear. The signed agreement remains in the document system. The project system owns the approved project record. The integration records which version it read, what it proposed, who approved it, and what write actually succeeded.

Ask the implementation partner to explain the integration in ordinary language. Which credentials does it use? What can it change? What happens when an API changes? Can your team disable it without disabling the underlying applications? Those answers define the long-term responsibility you are buying.

Commission a larger build only for a real product gap

A bespoke application may be justified when the workflow has important behavior that available products cannot support. That could include a specialized review process, a distinct customer interface, or a combination of constraints that cannot be represented safely in existing tools.

I would require evidence of that gap before accepting a larger build. List the required behaviors, show where the alternatives fail, and explain why simplifying the process is insufficient. Preference for a particular framework is not a business requirement.

A larger build also needs an operating owner. Someone must maintain dependencies, investigate incidents, review access, and pay for changes. If the proposal stops at launch, it has not described the whole purchase. Ask who takes over when the original developer is unavailable.

Compare the exit paths

Before choosing any option, ask what leaving it would involve. Can you export your records in a useful format? Do you retain source code where custom code is involved? Who owns the cloud accounts, domains, credentials, and deployment configuration?

Test export quality rather than accepting “export supported.” A file that omits attachments, relationships, approvals, or history may not be enough to continue operations. Document what is recoverable and what would have to be reconstructed.

For custom work, request a handoff rehearsal. A person who did not build the system should be able to find its configuration, deploy it in the agreed environment, and follow the incident instructions. That is a practical test of whether ownership has actually transferred.

Use a decision table with explicit disqualifiers

Score each option against the workflow, data access, exception handling, operating responsibility, integration limits, adoption effort, and exit path. Keep the scoring method simple enough that a business owner can explain it.

Some criteria should disqualify an option rather than merely reduce its score. If a solution cannot prevent one client's data from appearing in another client's work, a pleasant interface should not compensate. If it cannot support a required approval boundary, a lower price should not erase that gap.

Record unknowns separately. “We have not tested export” is different from “export failed.” Assign each unresolved item an owner and a test. Make the final decision after those tests, or explicitly accept the remaining uncertainty.

Run a bounded trial before expanding

Choose a small, representative set of cases and a defined observation period. Measure accepted outputs, correction effort, exception handling, and completion evidence. Include at least one case that should stop. Keep external actions under review until the relevant acceptance criteria pass.

Agree on the trial's exit conditions before it begins. What result supports continuing? What result means the design needs revision? What result means the project should stop? Without those conditions, a trial can become an indefinite demonstration that never produces a buying decision.

I would choose the smallest option that satisfies the workflow and leaves a clear owner for operation. Sometimes that is existing software. Sometimes it is an integration. Sometimes a custom application is justified. The decision should follow the tested gap.

Related reading

• Client onboarding automation for professional services: from signed scope to ready delivery, on TechTide AI
• Who approves the AI's work? A practical operating guide, on TechTide AI
• Protecting client data before connecting an AI workflow, on TechTide AI