Key takeaways
- ✓Ask who builds the software and whether they were part of the analysis
- ✓Make sure the code, the data and what the system learns belong to you
- ✓Ask about the cost of running it, not only the cost of building it
Why the demo is not enough
Choosing a partner for AI or custom software is hard, because the important differences are invisible at the start. Every serious partner can show a convincing demo and a good presentation. What you cannot see is how they deal with unclear requirements, exceptions, changes and problems after go live.
These ten questions help. Ask them in your first meetings, and pay attention not only to the answer but to how concrete it is. Vague answers now usually mean surprises later.
1. Who will build it, and were they in the analysis?
In many projects one team sells and analyses, and another team, sometimes in another country, builds. Every handover loses context. Ask who will write the software, whether they sit at the table during the analysis and whether the same people stay on after go live.
It also matters for quality. A developer who heard the client explain why a step exists will make better choices in the hundred small decisions no specification covers. A developer who only gets a ticket will build exactly what the ticket says.
2. What will I see after two weeks?
A partner who works in short cycles can show working software early, on your own data. If the first thing you will see is a finished product after months, you lose the chance to steer. Ask how often you will see progress and who on your side needs to give feedback.
3. Who owns the code, the data and what the system learns?
Get it in writing. Your data stays yours, and so should the rules and corrections the system learns from your team. Ask what you receive if you ever stop working together: the code, the data in a usable format and documentation someone else can work with.
Pay attention to the platform underneath, too. If the software is built on a framework or platform owned by the partner, ask what happens to licences and updates when the cooperation ends, and which parts you can keep running yourself.
4. Where is our data processed, and under which agreement?
When AI reads your mails and documents, ask where that happens, which subprocessors are involved and whether your data is used to train models. A serious partner answers in writing and offers a data processing agreement under the GDPR.
5. What happens when the AI is wrong?
AI is never right in every case. Ask how people approve what matters, whether every action is logged with its source, and whether a wrong action can be undone. A partner who claims the AI will simply be right has not built enough systems that people depend on.
Ask to see it: a screen where a person approves a proposal, a log that shows which source an answer came from, an example of an action that was rolled back. If it exists, it can be shown in a minute.
6. How do you test, and on which data?
Testing on clean examples proves little. Ask whether the system is tested on your real documents and mails, including the messy ones, and how you will know how often it is right before it handles work on its own.
7. What does it cost to run, every month?
The build is only part of the cost. Ask about hosting, model usage, licences, monitoring and support, and how those grow when you use the system more. A good partner gives you a realistic monthly figure before you start.
Also ask what the model usage costs at your volumes. For most SME tasks it is small, but the partner should be able to estimate it, and to explain how they keep it under control.
8. How do you handle change during the project?
Your process will change while the software is being built, because building it makes you see your work differently. Ask how changes are discussed, estimated and approved, and how that affects the price and the planning.
9. What happens after go live?
Ask who you call when something breaks, how fast they respond and who keeps improving the system. The first months after go live decide whether people keep using it. A partner who disappears after delivery leaves you with software that slowly stops fitting.
10. Can we leave if we want to?
It sounds like a strange question for a first meeting, but the answer says a lot. Software built with mainstream technology, documented and with your data accessible, keeps your options open. If leaving would mean starting over, you are not choosing a partner but a dependency.
How to compare the answers
Put the answers of two or three partners next to each other, question by question. Look for concrete examples rather than promises: a client you may call, a screen from a real project, a sample of the monthly report they send. Ask each partner which of the ten questions they find the hardest to answer. The honest ones will tell you, and that conversation says more than any presentation.
Price matters, but compare it last. A cheaper offer that leaves ownership, testing or support vague often becomes the expensive one.
Signs to be careful
A fixed price for a large project before anyone has looked at how you work. Promises of full automation in weeks. No clear answer on ownership. Nobody who can explain what happens when the AI is wrong. And a demo that only ever runs on the partner's own examples.
Put us to the test with these ten questions.
Tell us how the work runs today.
