How to choose an AI partner for your SME: 5 questions every vendor should answer

Every vendor who talks to you about AI says roughly the same thing. A fixed price. The code is yours. And it will be quick. Those are 3 promises you cannot compare, because everybody makes them and almost nobody writes them down in a way you can check.

So if you are working out how to choose an AI partner for your SME, do not start with the promises. Start with 5 questions: who works on it, where does it live, what does it cost to run, who picks up the phone in month 4, and how do you get out. A vendor who answers those 5 clearly can be compared. A vendor who talks around them can be compared too, it just goes differently.

This article is for the owner, managing partner or operations lead of a Dutch B2B service company with 10 to 200 people. You run an expert process by hand: subsidy applications, vehicle tax calculations, certificates, inspections, case files. You have no technical team of your own, and your growth stops at the next vacancy nobody fills.

It is not for you if you are still looking for an idea, building a consumer app, comparing hourly rates and nothing else, looking for a single Zapier flow, or writing a 6 month enterprise tender. Other articles will serve you better.

In this article you will learn the 5 questions to put to every vendor, what a good and a weak answer sound like, which kinds of providers exist and who each one suits, which questions vendors would rather not hear, which red flags to take seriously, and how to put 2 proposals side by side, with a worked example.

‍

Key takeaways

• Fixed price, code ownership and speed no longer set anyone apart. Every vendor promises them, so they will not help you choose.

• Ask every vendor the same 5 questions, always in this order: who, where, running cost, month 4 and the exit.

• Who: ask for names, not a team. And ask what else those people are working on.

• Where: the code, the data and the accounts belong to you from day 1, not from handover.

• Running cost: ask for an amount per month and per unit, with a cap and an alert before the cap is reached.

• Month 4: who answers when it breaks, within how many hours, and what that costs. This is where proposals differ most.

• The exit: what you pay and what you keep if you stop after month 1.

• A proposal that leaves 1 of these 5 blank is not cheaper. It has moved the bill to later.

‍

Why AI vendor promises cannot be compared

In 2025 the Dutch government commissioned research into how small and medium businesses use AI. A recurring wish among owners in the government study on AI use in Dutch SMEs is someone who can help map everything out properly. Not another tool. Someone who understands how the work runs today and what could run better.

Most proposals you receive answer a different question: what will we build and what does it cost. That is useful, but it says little about year 2. The questions that decide whether it still runs 18 months from now are usually missing.

Take the 3 standard promises. A fixed price, but for which scope, and what does everything after handover cost? The code is yours, but does it sit in your environment or in a zip file you receive at the end? It will be quick, but quick to a demo, or quick to something that runs unattended in your busiest month?

Fixed price, ownership and speed have become what a roof is to a house. Good that it is there, but nobody buys the house for it.

Something else has changed. Building software has become a lot cheaper over the past 2 years, because developers now work with coding assistants. The build is rarely the expensive or risky part anymore. The risk sits in what comes after: the exceptions, the connections to Exact, AFAS or your sector software, the model costs at volume, and the question of who fixes it when it goes wrong.

‍

5 questions every vendor should answer

We call this page one, because the answers belong on the first page of a proposal, before the price. Send these 5 questions to every vendor you are considering. The same questions, in the same order, in writing. Then you compare answers instead of sales talk.

‍

‍

You can copy them word for word:

• Who will work on our project, by name, and how many other projects are they on at the same time?

• In whose repository and whose accounts will it be built and run?

• What does it cost per month and per unit to keep it running, and where is the cap?

• If it breaks in month 4, who answers, within how many hours, and what does that cost?

• If we stop after month 1, what do we pay and what do we keep?

Below, for each question: why it matters, what a good answer sounds like, and what a weak answer sounds like.

‍

Question 1

On an AI project the knowledge lives in people's heads. The person who sits with your advisors on day 1 and hears how an application really runs should be the one who builds it and, later, hunts down the bug. Every handover between a salesperson, a project manager and a developer loses context. And context is exactly what a system needs to handle your exceptions well.

The second half of the question matters just as much. A good developer spread over 5 projects is a developer you mostly see on Friday afternoons. So do not ask only who, ask what else those people are doing.

A good answer: "2 people work on your project, and we name them before you sign. One sits in Amsterdam, the other in Utrecht. Each has 1 other project running. Both are in the first meeting, and both build it."

A weak answer: "You get our team of specialists." Or: "We will see who is available once the contract is signed." Or a team page with 14 smiling faces that tells you nothing about who works on your project on Tuesday.

Ask the follow up: who writes the code, who reviews it, and what happens if 1 of the 2 leaves? A vendor with a concrete answer is already thinking about your year 2.

‍

Question 2

Ownership on paper and ownership you can act on are 2 different things. If the code sits in the vendor's GitHub, the keys for the language model run on their account and the flows live in their Make or n8n workspace, what you own is a clause in a contract. Not a system.

It is also about data. Your clients send you sensitive material: annual accounts, licence plates, payslips, personal data. Where does it go? In which country does the model run, is the data used to train models, and who has access? Under the GDPR you are the one responsible, not the vendor.

A good answer: "We build in your GitHub organisation from the first commit and run in your cloud account, in an EU region. The model keys are in your name. We get access, you hold the keys. We write the documentation for a developer who has never met us. And a data processing agreement is signed before the first client file comes in."

A weak answer: "We hand everything over at delivery." Or: "It runs on our platform, so you do not have to manage anything."

That last one is not always wrong. A packaged product rightly runs on the vendor's side. Then the question shifts to: can I export my data, what happens if the price goes up, and what if the product is discontinued? Ask the follow up: may I see a finished project, repository and documentation, with that client's permission?

Want to turn these questions into a clean brief that every vendor reads the same way? The free AI product requirements template puts what you want automated, what it may cost and how you will judge vendors in 1 place.

‍

Question 3

After the build, ordinary software mostly costs hosting. AI software has a second meter running: every call to a model costs money. Per application, per file, per calculation. At 50 files a month you will not notice. At 2,000 you will.

A proposal that names only the build price leaves out exactly the line that grows with your success. Add hosting, monitoring and, for rented flows, a subscription that bills per operation and climbs the more you use it.

A good answer: "We expect 0.30 to 0.50 euro in model costs per application. At 800 applications a year that is 240 to 400 euro. Hosting is 60 euro a month. We put a cap of 50 euro a month on the model and you get an alert at 80%. If the system hits the cap, it queues the work instead of running up the bill."

A weak answer: "The API costs are negligible." Or: "It depends on usage." The second one is true, which is exactly why it needs an estimate and a cap.

Ask the follow up: what happens if the model provider raises prices or retires a model? Who replaces it, how long does that take, and who pays for the work?

‍

Question 4

Why month 4? For the first 3 months after launch, everything is still fresh in the builders' heads. Around month 4 the project team has moved on, and that is when the first real exception arrives. A subsidy scheme changes. The tax authority publishes a new form. A supplier changes its export format. This is where most AI projects die, usually without anyone calling it that.

The question has 3 parts and you want a concrete answer to each. Who answers, by name. Within how many hours, as a number, and whether those are working hours or weekends too. And what it costs: a fixed monthly amount, or hours billed afterwards.

A good answer: "The system is monitored, and the 2 people who built it are on the alert. We respond within a fixed number of working hours that is written in the contract. For an incident that stops your process, we fix it or roll it back within 1 working day. You pay a fixed amount per month and get 1 page every month: what ran, what broke, what it cost, what we are changing."

A weak answer: "Of course we will always help you." Or: "Support is billed on time and materials." A low monthly price with no response time tells you nothing about when someone will fix your problem.

Ask the follow up: what counts as an incident, who decides that, and is a month in which the agreed response time is missed free? Vendors who take their own support seriously have already thought about it.

‍

Question 5

You want to be able to stop before you fully trust someone. After month 1 you know whether the people fit: whether they listen, deliver on time, and say honestly what cannot be done. A good exit means stopping costs you what was delivered and nothing more. And you leave with something that works, not a folder of files nobody can run.

A good answer: "After month 1 you can stop. You pay for the milestones that are finished, at the amounts in the proposal. You keep the repository, the documentation and access to every account. Another developer can pick it up the following week."

A weak answer: "The contract runs for 12 months." Or: "The platform licence stays with us." Or: "Handover is a separate project."

Want to know how to make this and the other 4 answers stick in a contract? The 9 clauses to agree before you sign an AI contract goes through each clause to check, from ownership and liability to support and termination.

‍

AI agency or AI consultant: what is the difference?

The short answer: an AI consultant advises and maps, an AI agency builds. But those are not the only 2 options. Anyone looking for AI consultancy for an SME, or an AI partner in the Dutch SME market, will meet at least 7 kinds of provider. Each has its place, just not in every situation.

AI consultant

A consultant analyses your processes, looks for opportunities and writes advice or a plan. That fits when you do not yet know where AI helps you and want an independent view first. It fits less when you already know which process you want automated: then you pay for a plan somebody else has to build. Always ask who will carry out the advice. There is more on this role in what an AI consultant does day to day.

AI agency

An AI agency builds custom work: integrations, agents, a platform. That fits when your process is specific enough that no package covers it and you have the volume. The risk sits in questions 1 and 4: who really builds it, and who is there after launch. The difference between these firms is rarely the technology and almost always those 2 answers.

Automation shop with rented flows

These providers build automations in n8n, Make or Zapier, often starting at 1,500 to 5,000 euro. That is an excellent fit for a single, simple process at low volume. It fits less for your core process: the flows often run on their account, the platform bills per operation, and the connection to your sector software sometimes cannot be made. Ask questions 2 and 3 with extra care here.

Freelancer

A good freelancer is quick, affordable and directly reachable. That fits a well defined job with someone you know. It gets harder at question 4: 1 person goes on holiday, falls ill or takes a full time job. Ask who covers for them and where the documentation lives.

Nearshore team

A team in, say, Poland or Romania costs a lot less per hour than a Dutch developer. That fits when you have someone in house who writes the tickets, reviews the work and decides the architecture. If that person is you, you are buying hours, not an outcome. Good nearshore teams will tell you so themselves.

A packaged sector product

For accountancy and legal work there are more and more AI products priced per user. They fit when your work resembles your competitors' and the product covers your standard process. They fit less when your edge is exactly the way you do it differently: that edge is not in the package, and you cannot sell it to your own clients either.

A hire

In the end every company that runs on software needs people of its own. A senior developer in the Netherlands earns 65,000 to 95,000 euro gross a year according to Dutch recruitment figures. With about 30% employer costs, that is roughly 85,000 to 125,000 euro, and the search often takes months. Hiring fits when you are sure there are years of work and you can direct that person. Without a technical colleague to think with, it is a lonely job, and you will see that in the turnover.

‍

Questions vendors would rather not hear

The 5 questions on page one are fair to everyone. On top of those, some questions quickly show whether a vendor knows its own work. Ask 2 or 3 in the first meeting, and listen mostly to how long the answer takes.

• May we call a client who has been live for more than a year, before we sign? Many providers are not yet 3 years old. A client in year 2 tells you more than 10 case studies.

• Which of your case studies are still running today, and which were switched off? An honest list, failures included, is a good sign.

• How much of the code comes from a code generator, who reviews it, and may we see a review? Everyone uses those tools. The question is who signs for what comes out.

• What is the AI in your design not allowed to do on its own, and where does a person approve? Where a mistake is expensive, a person should sign.

• How do you test that a change in part A does not break part B? Ask them to show it, not explain it.

• What happens to the automation if the platform it runs on changes its prices or drops an integration?

• When do you say no to a project? A vendor who never says no has not understood your process yet.

‍

Red flags in an AI proposal

Some signals are not a reason to walk away at once, but they are a reason to ask more. If you find 3 or more in the same proposal, take your time.

• Roles instead of names: "a project manager", "an AI specialist".

• A price for the build and nothing about what it costs afterwards.

• "Unlimited support" with no response time, or a response time with no number.

• Code, flows or model keys that stay on the vendor's account.

• A demo with your logo but without your real files or data.

• A promise of hours saved with no client name or calculation behind it.

• A 12 month contract before anything runs at all.

• An AI that decides and sends on its own where a mistake costs money or a client.

• Not a single "we would not do that" in the whole conversation.

‍

How to compare 2 proposals side by side

Make a sheet with 1 column per vendor and 7 rows: the 5 page one questions, the build price, and the total cost over 24 months. Fill in what the proposal literally says. An empty cell means "not answered", not 0. Then calculate over 2 years, not over the first invoice.

An example, not a client. An advisory practice with 30 people files 800 subsidy applications a year. Finding and matching the right scheme takes an advisor 2 hours per application. That is 1,600 hours a year, which at an internal 80 euro an hour is 128,000 euro.

Proposal A comes from an automation shop. Build 4,500 euro, on a rented flow running on their account. Platform subscription 250 euro a month. Model costs "negligible". Support billed at 110 euro an hour, no response time. Nothing about the exit.

Proposal B comes from a development team. Build 32,000 euro fixed, in the practice's own repository and accounts, with 2 names on it. Support 1,100 euro a month from launch in month 3, with monitoring and a response time in hours. Model costs 0.40 euro per application, with a cap. After month 1 you can stop and pay for what was delivered.

Over 24 months, A costs 4,500 plus 24 times 250 on paper, so 10,500 euro. Add 3 incidents a year of 8 billed hours each and you add 5,280 euro: roughly 15,800 euro in total, plus model costs nobody estimated.

B costs 32,000 plus 22 months of support at 1,100, so 24,200, plus 640 euro in model costs over 2 years. Roughly 56,800 euro in total. On paper, A is 41,000 euro cheaper.

Now the other side of the sum. Say A only speeds up the search, because the flow cannot read the case management system, and halves the time per application. That saves 800 hours a year, 64,000 euro. Say B handles search and the first draft together, connected to the case system, and saves 1,200 hours: 96,000 euro a year. Even if A runs from month 1 and B only from month 3, B saves about 48,000 euro more time than A over 2 years.

So on money they are close. What decides it are the rows A left empty. Take month 4. In the busiest subsidy season A's flow stops, with 80 applications in the queue. No response time was agreed, so you wait until someone has time. Every day it stands still, 10 advisors go back to searching by hand.

Does that mean B always wins? No. At 150 applications a year the saving is too small for a 32,000 euro build and A is the better choice. The point is that you only see this once both columns are full. With only the build price, you nearly always pick the wrong proposal for the wrong reason.

‍

How we fill in page one

We would be a poor example if we did not answer these questions ourselves. Codelevate turns Dutch B2B service companies into software companies: we map the expert process you run by hand, automate it so the same team handles the volume, and build the platform your customers pay for, with 2 engineers by name from the blueprint to year 2.

Who: the 2 engineers on your project are named in the proposal, with their other work listed and where each of them sits. Codelevate, Amsterdam and Sofia, since 2019.

Where: in your repository and your accounts, from the first commit. Your systems stay: we connect to Exact, AFAS and your sector software.

Running cost: the cost per unit is in the proposal, with a cap. Where a mistake is expensive, a person approves.

Month 4: monitoring, a named engineer on the alert, the AI cost per unit capped, a 1 page report every month, and model and rule updates. The response time is set in the Blueprint. As a planning value we use 1,250 euro per month per automation.

The exit: Exit after month 1: pay for what is delivered, keep everything.

The first step is usually the Blueprint: 2,500 to 10,000 euro depending on the number of processes, in 10 to 20 working days. You get the process mapped as it really runs, the bottlenecks priced in hours and euro, the AI opportunities ranked, a roadmap with fixed prices per milestone and a first rough prototype in your own repository. Automating a major process then costs 18,000 to 45,000 euro, fixed. If you would rather build it in house after the Blueprint, that is fine: the plan is yours.

Examples, anonymised: a vehicle tax (BPM) file processor went from 4 to 8 hours per file to under 5 minutes. A subsidy matching engine went from hours of expert searching to seconds. And at a subsidy advisory, 5 advisors worked 5 ways in 5 tools. We have published 24 cases, 8 of them B2B platforms, and hold Clutch 5.0 over 10 reviews, 7 of the 10 by referral.

And sometimes the honest answer is that you are better off with a package or a hire. Then we say so.

‍

In short: compare answers, not promises

You do not choose the right AI partner for your SME on the nicest promise. You choose on the 5 answers that belong on page one: who, where, running cost, month 4 and the exit. Send them to every vendor, put the answers side by side, and calculate over 2 years instead of the first invoice.

Want the questions, the scope and your requirements in 1 document you can send to every vendor? Download the free AI product requirements template and fill it in before your first meeting.

Ready to choose? Send us what you have: a process description, a price list, a spreadsheet or the proposal already on the table.

1 of the 2 engineers reads it with you in 20 minutes, and you get 1 of 3 answers in writing the same day: do it in house, hire, or the Blueprint.