# How to choose an AI development partner

> Choose an AI development partner by how they work, not by what they promise. Look for one that shows you working software early, starts with read-only access and earns permissions, explains trade-offs plainly, hands over documentation, and prices the ongoing run cost alongside the build. The best test is a small first engagement with a clear definition of done.

Source: https://risendigital.io/guides/how-to-choose-an-ai-development-partner  
Publisher: Risen Digital  
Updated: 2026-09-21

## At a glance

- **First test:** Ask to see something running on your data within the first few weeks, not a slide deck about what will run later.
- **Permissions:** A careful partner starts read-only, lets people approve every action, and widens access only on evidence.
- **Biggest red flag:** Answers that are all outcome and no mechanism. If they cannot explain how it works, they cannot explain how it fails.
- **Cost to ask about:** The monthly run cost after launch: model usage, hosting, monitoring and the people who keep it healthy.
- **Good first engagement:** One bounded process, a fixed scope, a working result you keep, and a decision point before anything larger.

Most AI projects fail on the working relationship, not the model. This guide gives you the questions to ask, the answers that should worry you, and a scorecard you can fill in during the second meeting.

![Three people in discussion around a meeting table](https://risendigital.io/images/experience/pro-table-1600.jpg)

## What should you look for in an AI development partner?

Look for a partner whose habits reduce your risk: working software early, narrow permissions, honest trade-offs, and a plan for handing the system over to your team.

An AI project has more unknowns than a normal software project. The model can be wrong in ways that look right, the data you hold is rarely as clean as you think, and the useful part is usually the integration with systems you already run. A partner's job is to surface those unknowns early and cheaply, before you have committed to a large build.

That means the qualities to look for are mostly about working style. Anyone can describe an impressive end state. Fewer will show you the first rough version, tell you what it got wrong, and explain what they will change next. Those are the ones to shortlist, and the scorecard further down turns those habits into something you can rate.

## What questions should you ask an AI vendor before you sign?

Ask about mechanism and failure, not about outcomes. A good partner answers with specifics; a weak one answers with adjectives.

| Question | A good answer sounds like | A worrying answer sounds like |
| --- | --- | --- |
| What will I see running by the end of the first month? | A named process, on your data, in draft mode, with a demo date. | A design document and a roadmap. |
| What access do you need on day one? | Read-only to two or three systems, with a written list of what widens later and why. | Admin credentials to everything so we can move fast. |
| How will the system be wrong, and how will I know? | Specific failure modes, a review queue, and a measure of how often drafts are accepted unchanged. | It will not be wrong, or it learns from its mistakes on its own. |
| Who owns the code, the prompts and the data? | You do, in a repository you can see from the start. | It lives on our platform; you can export if you leave. |
| What does it cost to run after launch? | A breakdown: model usage, hosting, monitoring, support hours, and what drives each. | It depends; we will work it out later. |
| Who will I be talking to each week? | Named people, including the engineers doing the work. | An account manager, and the team varies. |

Ask for two references you can call, and ask those references one thing above all: what went wrong, and how did the partner handle it? Every project has a difficult week. How a team behaves in that week tells you more than any case study.

## How do you score a prospective AI partner objectively?

Rate each partner on the same seven habits during or straight after the second meeting, before the pitch has faded and before the price has anchored you.

_Interactive on the web page: Score a prospective partner. The scorecard rates a prospective partner on seven habits: showing working software early, starting read-only and earning permissions, explaining trade-offs plainly, handing over documentation and training, integrating with what you already have, pricing the run cost alongside the build, and offering references you can call. A partner who scores low across the board is selling a vision rather than a working method. A partner who scores high on most dimensions but low on one or two is worth a further conversation about those specific points before a first engagement._

Scores are only as honest as your evidence. If you are rating a dimension on what the partner said rather than on what you saw, mark it one level lower.

## What are the red flags when choosing an AI development partner?

The common warning signs are a demo that never touches your data, a request for broad access on day one, a price that stops at go-live, and a team that changes after the contract is signed.

- **The demo never becomes your demo** A polished demonstration on sample data is easy. If weeks pass and nothing runs on your records, the hard part has not started.
- **Everything needs admin access** A team that cannot work with read-only access first has not thought about how to limit the damage when the system is wrong.
- **The model is the whole story** If the conversation is about which model is best and not about tools, permissions, review queues and hand-off, the plan is missing the parts that make an agent safe to run.
- **A build price with no run price** Model usage, hosting and monitoring continue every month. A quote that stops at go-live is incomplete.
- **The team you met is not the team you get** Ask who will do the work and whether you will speak to them directly. Layers between you and the engineers slow every decision.

> **One question that exposes most of these** Ask: what would you do in the first two weeks if we signed today? A specific answer that names your systems and a first process is a good sign. A generic onboarding plan is not.

## What does a good first engagement with an AI partner look like?

A good first engagement is small, bounded and real: one process, a fixed scope, a working result you keep whether or not you continue, and a clear decision point at the end.

1. **Pick one process together** Choose something repetitive and documented where a wrong action can be caught and reversed. The partner should push back if your first choice is too big.
2. **Agree what done means in writing** A short document: the process, the systems involved, what the software will do, what a person still does, and how you will both judge the result.
3. **Start read-only, in draft mode** The software reads your data and proposes actions. People approve. Nothing goes live without a person for the whole first engagement.
4. **Review weekly, with the engineers present** Look at real cases, including the ones it got wrong. Watch how the team responds to a mistake; that is the working relationship you are buying.
5. **End with a decision, not a drift** You should leave with working software, documentation, a list of what to widen next and a run cost estimate. Then decide whether to continue, and on what terms.

If a partner resists this shape, ask why. There are honest reasons, such as a process that genuinely cannot be split, but the default should be to start small and let evidence drive the next step.

## Frequently asked questions

**Q: How do I know if an AI vendor is any good before hiring them?**  
A: Ask them to show you something running on your data, however rough, before you commit to anything large. Ask how the system will be wrong and how you will know. Call their references and ask what went wrong on their project. A vendor who is comfortable with all three questions is usually worth a first engagement.

**Q: Should an AI development partner need access to all of my systems?**  
A: No. A careful partner asks for read-only access to the two or three systems the first process touches and writes down how and when access will widen. Broad access on day one is a sign that the risk of a wrong action has not been thought through.

**Q: Is it better to hire an agency or build an in-house AI team?**  
A: It depends on how many AI projects you expect and how quickly you need the first one. A partner brings patterns from other projects and can start sooner; an in-house team knows your business and stays. Many companies use a partner for the first engagement on the condition that documentation and training let their own people take over.

**Q: What should the first AI project with a new partner be?**  
A: One bounded, repetitive, documented process where a mistake can be caught and reversed, with a written definition of done. It should produce working software you keep whether or not you continue, and end with a decision point rather than an automatic extension.

**Q: What should I ask an AI vendor's references?**  
A: Ask what went wrong and how the vendor handled it, whether the team they met was the team that did the work, whether they received documentation they could use, and what the system costs to run now. Avoid questions that invite a general recommendation; you want the difficult week, not the summary.

## Related pages

- [Build vs buy AI software](https://risendigital.io/guides/build-vs-buy-ai-software)
- [AI readiness checklist](https://risendigital.io/guides/ai-readiness-checklist)
- [AI data privacy and security questions](https://risendigital.io/guides/ai-data-privacy-and-security-questions)
- [The RISE method](https://risendigital.io/guides/the-rise-method)