Why the Vendor Who Built Your App Cannot Always Add AI to It

Your current mobile vendor built the app. They know the codebase, the architecture, the third-party integrations, and the release process. That institutional knowledge has real value. It is also entirely separate from the question of whether they can deliver AI features.

Mobile development and AI feature delivery are overlapping skill sets, not identical ones. A vendor who is excellent at building and maintaining a mobile app may have no experience integrating on-device models, managing inference latency, navigating AI-specific privacy reviews, or running the quality assurance process that AI features require. The gap is not about effort or good intentions - it is about whether the skills exist on the team.

The gap is not about ambition

Vendors who cannot deliver AI features typically have no shortage of ambition or willingness. The gap is in the specific technical experience that AI feature delivery requires.

On-device AI integration is categorically different from standard mobile feature development. The model needs to be selected, converted to a mobile-compatible format, optimized for the target device's memory and processor constraints, integrated into the app, and tested for latency, accuracy, and battery impact. None of this is standard mobile development work. A team that has never done it will take three to four times longer than a team that has, and may not produce a result that meets production requirements regardless of timeline.

Cloud-connected AI features are more accessible but still require experience with API rate limiting, latency management, error handling for model failures, and the cost modeling that makes the feature financially viable at scale. A vendor who has integrated standard REST APIs but never integrated an AI inference API will encounter unexpected problems at the integration and production stages.

What AI delivery actually requires

Four specific capabilities separate vendors who can deliver AI features from vendors who cannot.

Model integration experience. The vendor should have integrated at least one AI model - on-device or cloud - into a production app. Not a prototype. A live app with real users. The integration should include performance testing, edge case handling, and a documented approach to model updates.

AI-specific QA process. Standard mobile QA tests whether features work correctly. AI QA tests whether model outputs are accurate, consistent, and within acceptable bounds. These are different tests requiring different tooling. A vendor without an AI QA process will ship AI features that pass standard QA and fail in production.

Privacy review experience. AI features that process user data require a privacy review that standard features do not. A vendor who has not navigated an App Store review with an AI feature, or a GDPR or HIPAA privacy assessment with an AI data flow, will encounter delays and rejections they did not anticipate.

Cost modeling for inference. Cloud AI features have per-query costs that scale with usage. A vendor who does not model inference costs during scoping will deliver a feature that is financially unviable at the usage levels the business projects.

How to test your vendor before committing

The proof-of-concept test is the fastest way to validate AI delivery capability. Scope a six-week phase with a specific deliverable: a working prototype of the first AI feature in a test environment.

Define the success criteria before the phase starts: the feature runs in the test environment, produces outputs that meet the accuracy threshold, and performs within the latency target. Give the vendor the six weeks and the resources they need. Review the prototype against the criteria.

A vendor who delivers a working prototype that meets the criteria has demonstrated the capability. A vendor who delivers a prototype with significant gaps, or who requests an extension before the deliverable is due, has given you the answer you needed at a cost of six weeks rather than six months.

The three paths forward

Once you have assessed your current vendor's AI capability, three paths are available.

Your current vendor delivers the AI work. This is the lowest-coordination path and preserves the institutional knowledge they have about your app. It is only viable if they pass the proof-of-concept test. Do not take this path on the assumption that they will figure it out.

A specialist vendor works alongside your current vendor. The current vendor maintains the app. The specialist delivers the AI feature and integrates it. This adds coordination overhead but preserves institutional knowledge while adding genuine AI capability. The cost premium is 10 to 20 percent. The risk premium is significantly lower than path one if the current vendor does not have AI delivery experience.

A new vendor takes over both. If the AI mandate is large enough - and if the assessment reveals that the current vendor's limitations extend beyond AI into general delivery quality - a full transition may be the right answer. This carries the highest transition cost but produces a single point of accountability for both the app and the AI feature.

When loyalty to your current vendor costs you

Sticking with a vendor who cannot deliver AI features because they built the app is a category error. The institutional knowledge they hold is valuable. It is not valuable enough to justify a six-month timeline slip on a board-mandated project.

The loyalty cost shows up in three ways: a prototype that never becomes a production feature, a timeline that extends quarterly without a clear root cause, and a board update in month six where the honest answer is that the vendor does not have the capability.

The structured test eliminates the ambiguity. Six weeks to validate. A clear success criterion. A decision point that produces either a confident path forward or an early course correction.