AI Integration vs Custom Development

Choose AI integration when the required business capability already exists and the main work is connecting it safely to AI interpretation or assistance. Choose custom application development when the business needs a capability that no existing system provides. Many projects need both. The useful boundary is what owns the business behaviour, not whether engineers write custom code.

This guide helps product owners, enterprise architects and IT directors scope AI integration and delivery. An adapter can be custom-built integration work. A new workflow application can use standard connectors. Calling everything “integration” can hide missing product requirements; calling everything “custom development” can recreate capabilities the organisation already owns.

Inventory capability before selecting an approach

Describe the intended business outcome in verbs and states. For a membership application process, these might be receiving an application, checking required evidence, requesting clarification, recording a reviewer decision and publishing an approved status. Ask which existing system owns each state and whether its supported interfaces expose the required behaviour.

A screen demonstrating a feature does not prove it is available through an integration interface. A database table does not prove that writing to it executes the application's rules. Confirm supported operations, permission checks, transaction boundaries and side effects. The existing-system integration guide explains how to discover those constraints without assuming every visible feature is programmable.

Record capability gaps separately from connection gaps. A connection gap might be the absence of a supported event notification, requiring a controlled polling design. A capability gap might be the absence of an appeals process with assignments, deadlines and reviewer decisions. The first concerns accessing existing behaviour; the second requires defining new behaviour.

Use a capability ownership worksheet

Illustrative worksheet for membership application assistance

Required capability	Existing owner	Likely work	Acceptance question
Member identity	Membership platform	Authorised lookup and matching	Is the correct member identified without cross-record exposure?
Evidence extraction	No current AI component	Bounded AI service and integration	Are fields supported and uncertainty visible?
Reviewer decision	Existing platform workflow	Draft submission through supported operation	Does the authorised reviewer retain decision control?
Appeal assignment	No existing capability	New workflow capability or suitable product extension	Are assignment, deadlines and decision history defined?
Published status	Membership platform	Confirmed update after approved decision	Is one authoritative status maintained?

This hypothetical worksheet is a discovery aid, not a recommendation to build a membership product. Its value is exposing the place where a proposal stops connecting existing capabilities and starts creating a new one. Complete the worksheet with system owners before estimating the implementation.

Keep adapters narrow and explicit

An adapter translates between the meanings and contracts of systems. Microsoft's anti-corruption-layer pattern describes a boundary that translates between subsystems with different semantics. This can protect a new service from being shaped by every legacy detail. It still requires ownership, tests and operational support.

Suppose one system uses “active” for an approved member, while another uses it for an application still being processed. A field-to-field copy would preserve the spelling and change the meaning. The adapter should perform an explicit mapping with unknown states rejected or reviewed. That is integration logic with business consequences, even if it contains only a few lines of code.

Do not let the adapter gradually become an undocumented second application. If it starts assigning reviewers, calculating appeal deadlines and maintaining decisions that exist nowhere else, recognise the new capability. Give it a product owner, state model and acceptance criteria. Hidden capability is harder to maintain than acknowledged custom development.

Recognise when a new application is justified

Custom development may be appropriate when the required process is distinctive, important and unsupported by suitable existing products or extensions. Define the users, cases, permissions, states, exceptions and evidence before designing screens. AI assistance should fit inside that process rather than become the only mechanism defining what happens next.

Evaluate whether a supported extension to the current platform can supply the missing capability. Compare its constraints and lifecycle with a separate service. A separate application can isolate change but adds identity, integration, operations and data-consistency responsibilities. An embedded extension can simplify the user experience while tying maintenance to the platform's release and licensing conditions.

For the hypothetical appeals process, a new capability might need assignment, reviewer substitution, evidence versions, decision reasons and controlled reopening. These are product behaviours, not merely API connections. The AI component might summarise the evidence, but the application must still enforce who can decide and which state transitions are allowed.

Define one authority for each business fact

Creating a new application does not justify duplicating authoritative data without a plan. Decide which system owns member identity, application state, appeal outcome and published status. A local copy may support performance or evidence preservation, but it needs a freshness definition and a conflict rule. Avoid two interfaces that can independently edit the same fact without reconciliation.

Consider a reviewer decision accepted in the new application while the membership platform is unavailable. The application should retain a pending synchronisation state and an operation reference. It should not report the published status as changed until the destination confirms it. If the destination rejects the update because its state changed, an authorised owner must resolve the conflict.

The same principle applies to a custom CRM integration. Owning the source code does not remove the need for a business contract. The architecture-pattern comparison helps select synchronous, queued or event-based communication once the capability ownership is clear.

Compare lifecycle obligations, not just initial effort

Integration work carries connector maintenance, source-version changes, contract tests, credential lifecycle, recovery and monitoring. Custom application work adds product requirements, user experience, domain rules, data migration and ongoing feature ownership. Some costs overlap, so estimate them by responsibility rather than charging the same activity twice under different headings.

Ask who will maintain each component after delivery. A one-off adapter may be stable if its contract is narrow and its dependencies are managed. A new case-management capability needs a backlog owner when users request changes. If nobody can own those future decisions, the organisation has not completed the build-versus-integrate decision.

Compare the consequences of exit. Can another team operate the adapter from the documented contract? Can it understand and modify the custom application's state model? Does the organisation control repositories, deployment configuration and data exports? “Custom” does not automatically mean independent, and “integrated” does not automatically mean locked in.

Run a boundary-focused feasibility exercise

Choose one representative case that touches the most uncertain boundary. Demonstrate source access, interpretation, the authorised destination operation and the confirmed business result. Then demonstrate an exception, such as a reviewer acting on a stale application. The purpose is to expose whether the difficulty is interface access, ambiguous business rules or a genuinely missing capability.

Do not let a prototype create an apparent capability by bypassing the system that must own it. Writing directly to a staging table or asking an administrator to finish every case may be acceptable in a labelled experiment, but the production proposal must include the real workflow and authority. Record the remaining gap instead of pricing the demonstration as if it were the completed service.

A new model endpoint alone also leaves surrounding responsibilities unresolved. The API-only comparison explains that distinction. Where an ERP already owns deterministic transactions, use the AI versus ERP integration comparison to keep AI interpretation separate from the transaction's authoritative rules.

Accept the adapter and the new capability differently

An adapter can be accepted against its mapping, permission behaviour, interface compatibility and recovery contract. A new application capability needs those checks plus evidence about its business states and user decisions. In the membership example, proving that an appeal record can be saved does not prove that reviewers can substitute for one another or that a withdrawn appeal cannot be decided.

Create a small state-transition exhibit for the new capability: starting state, authorised actor, requested action, conditions, resulting state and retained reason. Include a disallowed transition and a concurrent update. The business owner should recognise the process in this exhibit before the engineering team implements it.

Keep that exhibit out of the adapter's hidden logic unless the adapter is explicitly being promoted into an application service. Otherwise a future team may replace a connector and accidentally remove business behaviour nobody knew it owned. Separate acceptance records make both the initial scope and future maintenance boundary easier to understand.

Write the scope as separate delivery outcomes

Split the proposal into the capability delivered, the interfaces connected and the operating evidence required. Name exclusions explicitly when they affect the outcome: an appeals workflow, a new portal or a platform upgrade should not be silently assumed. Use the integration statement of work to define who accepts each part and how a discovered capability gap changes scope.

For related commercial reading, Trusted Data's AI integration for SaaS products guide discusses product integration boundaries. Bring a capability worksheet, the existing system operations and one unresolved exception to an enquiry. Discuss which parts of your AI project need integration or new development so the delivery plan reflects the actual business gap.