When someone builds your AI application, the thing you see is a link. You open it, it works, the demo goes well. It is tempting to treat that link as the deliverable.
A working URL is not the whole deliverable. The real test is simpler and harder: if the person who built it disappeared tomorrow, could you keep running it, fix it and change it?
This is my view of what a founder should ask for. It is not an industry standard, and every project is different. But I have shipped more than 50 platforms and sold my startup, Stacks, to EBSCO, and these are the things I would want in my own hands.
The code, in your repository
The repository should live in your organization's account from the first day, not get transferred at the end. You should be able to see every change as it happens, add and remove people yourself, and keep the full history if you change builders.
Ownership should be explicit in writing too. The code, designs, prompts and documentation should belong to the company, with no loose ends. I wrote more about why in what selling a startup taught me.
The accounts, in your name
An AI application usually depends on more accounts than founders expect: hosting, the database, the domain, email sending, analytics, error tracking and one or more AI providers.
Each of those should be in your name, on your billing, with the builder given access rather than ownership. If the AI provider account sits on someone else's card, your product stops working when their card does. If the domain is registered to the builder, you do not really own your product's address.
How to run it
You should get written instructions a new engineer could follow on their first day:
- What environments exist, and what each one is for.
- How a change gets from a laptop to production, and how to roll it back.
- Where secrets and keys are stored, without the values themselves in the document.
- How to set the project up locally and run the tests.
If the only person who knows how to deploy is the builder, you have a dependency, not a product.
What it depends on
Ask for a plain inventory of third-party services and significant libraries: what each one does, whose account it is under, and what would happen if it went away or changed its terms.
For AI features, that inventory should include which model each feature uses and where the prompts live. Prompts are part of the product. They belong in the repository with the code, versioned and reviewable, not in someone's head or in a provider dashboard nobody else can see.
What it does not do yet
Every product ships with known limitations, unfinished work and shortcuts taken to hit a date. That is normal. What is not normal is finding out about them from customers.
A good builder writes these down and hands them over: what is missing, what is fragile, what was deliberately kept simple and when it will need attention. An honest list is a sign of a careful builder, not a weak one.
How you will know the AI still works
This is the part most specific to AI applications, and the one most often missing.
Ordinary code behaves the same way every time. AI features do not, and they can change when a prompt is edited or a model is updated. So you should receive a set of examples for the important AI behaviors: realistic inputs, what a good result looks like for each, and a way to run them again. Without that, nobody can safely change a prompt or switch models, including the next team you hire.
Alongside that come the ordinary safeguards: automated tests for the paths that would hurt users or the business if they broke, and a security review before real users arrive.
What I hand over
In my own engagements, some of this is a fixed commitment:
- Code, documentation and IP in your repository, owned by you.
- No lock-in. Everything lives in your accounts.
- Automated tests and a security review as part of every v1 build, with your sign-off on every release.
- Weekly written updates, so you always know what I am working on, what I decided and why.
- An NDA on request.
- The written rules my coding agents worked under, which come with the codebase so your team can keep building the same way.
If you cannot run it without the person who built it, you have not received the whole product.
Questions to ask before you sign
- Will the repository and every service account be in our name from the start?
- Who owns the code, designs and prompts, and is that in writing?
- What documentation will we get for running, deploying and updating it?
- What third-party services and models does it depend on?
- How will we know if an AI feature gets worse after a change?
- What will you tell us about known limitations and unfinished work?
- If we part ways, what does the handover look like?
A builder who answers those clearly is usually one you can trust with the rest.
If you are about to have an AI product built and want to talk through what to ask for, email me.