Buying AI-Built Software: What to Verify Before Acquisition

1. Distinguish AI-built from AI-powered

AI-built software was developed substantially with coding assistants, agents, or app builders. AI-powered software uses models at runtime. A product may be either, both, or neither. The terms should not be used interchangeably in an acquisition scope.

For AI-built products, the review examines the delivered system and how it can be operated and changed. For runtime AI features, additional questions can concern model-provider dependence, data handling, output behavior, usage costs, and evaluation. Those require an agreed scope and, where necessary, specialist input.

Code inspection alone cannot reliably establish AI authorship or prove provenance. Request development and dependency evidence where relevant, and refer IP ownership questions for legal review. Do not treat a detector’s score as proof of ownership or a codebase’s quality.

2. Establish what the buyer will actually control

A source-code export is not the whole operating asset. Inventory the builder workspace, hosting, domain, identity provider, databases, file storage, billing account, email service, integrations, and deployment credentials. Identify which belong to a founder personally and which can transfer under provider terms.

Ask a replacement operator to explain the route from a reviewed revision to a running environment. Check that required configuration and dependency versions can be recovered without a chat history or a builder session held only by the founder.

• Request: account and asset inventory, export/rebuild instructions, deployment configuration, and responsibility map.
• Check: an authorized walkthrough of a build or deployment in a safe environment using documented inputs.
• Decision: unresolved transfer or reproducibility dependencies become explicit transition conditions. Do not assume platform exports are complete or legally transferable.

3. Trace the workflows on which the business depends

Choose the workflows whose incorrect behavior could materially affect customers or operations. For a subscription service, those may include signup, tenant access, invoicing, payment notifications, entitlements, cancellation, and deletion. Agree the actual scenarios; this is not a universal test suite.

For each workflow, ask what happens after a retry, duplicate notification, timeout, partial failure, or restart. A page displaying success does not establish that the resulting business state is correct. Compare stored state, external provider state, and any reconciliation process.

4. Inspect security boundaries beyond the interface

A hidden button does not demonstrate an access restriction on the server. Examine how the application authenticates users, associates them with an organization, authorizes actions, validates critical inputs, and manages privileged access. Focus the review on the routes and data relevant to the agreed risks.

OWASP ASVS provides requirements for application security controls that can inform selected checks. A scoped technical assessment is not a claim that all ASVS requirements were tested, nor a replacement for penetration testing. Production tests that could affect data or third parties need separate written authorization.

• Request the role model, authorization implementation, secret storage arrangements, dependency inventory, and relevant test cases.
• Differentiate an observed failure from an untested risk. Record the revision, environment, account permissions, and coverage boundary.
• Never request production customer records or shared administrator passwords merely to make an initial inquiry easier.

5. Check whether a new engineer can change the product safely

Ask how a small, plausible product change travels through implementation, tests, review, release, and rollback. Inspect whether business rules are duplicated, framework conventions are followed, migrations are repeatable, and generated or builder-managed areas can be maintained without breaking regeneration.

Missing tests are a risk indicator, not an automatic conclusion that a rewrite is necessary. Investigate the critical behavior and the cost of establishing regression safeguards. A targeted repair may be sufficient; a broader redesign needs evidence about system boundaries and change constraints.

NIST SSDF can inform questions about secure development practices. It does not establish that any particular AI-assisted codebase is secure or insecure. The result should describe observed practices and gaps, not judge the product from the tool used to build it.

6. Verify recovery of the business process, not just the database

Database restoration can leave external files, queued work, payment state, identity configuration, or third-party integrations inconsistent. Map the state needed to resume the critical workflow, then ask what recovery evidence covers those dependencies.

AWS’s transactional outbox guidance describes the inconsistency risk when a database update and a message notification are separate writes. An outbox is one possible design response, not a universal repair. Its presence does not by itself prove reliable processing; duplicate handling, ordering, dispatch, and reconciliation still need consideration.

Fictional illustration: restoring invoices from a backup while losing pending external work can leave the application apparently healthy but operationally incomplete. This is a failure scenario to investigate, not a claim that a reviewed product suffered that loss.

7. Put operational independence into the transition plan

A founder can be helpful while remaining a single point of dependence. Ask the intended successor to demonstrate routine release, diagnosis of a plausible incident, and recovery using documented procedures. If that cannot yet be demonstrated, identify the missing access, knowledge, or engineering work.

Classify the outcome into evidence needed before a decision, conditions for handover, and work that can reasonably be planned afterward. Estimate engineering effort only for defined outcomes. Any cost scenario needs explicit rates, role assumptions, dependencies, and exclusions. Avoid a blanket stabilization price based on the label ‘AI-built.’

The buyer is acquiring an operating and changeable product, not merely a fast development story. A focused assessment can investigate selected high-risk areas; comprehensive diligence broadens the agreed coverage without promising exhaustive defect detection.