The one question to ask any AI vendor before you sign

Before you sign with any AI vendor, including mine, ask one question. Does the vendor get paid when the workflow works, or when the engagement continues? The answer tells you more about how the project will go than the demo or the case studies will.

I would put it in exactly those words, because vendors are good at answering softer versions of it. “How do you measure success?” invites a slide. The question about payment invites a contract clause, and contract clauses are much harder to talk around.

Why the payment trigger matters

Every contract rewards something. If the vendor is paid by the hour or by the month, the contract rewards time spent, and the longest projects become the most profitable ones. Nobody needs bad intentions for this to go wrong. Scope grows and a pilot turns into a second pilot, and each step is reasonable on its own while the meter keeps running.

If the vendor is paid when the workflow works, the incentives point the other way. A vendor in that position wants a narrow scope and written criteria for what “works” means, since vague criteria put its own payment at risk. It also wants to finish, because the money arrives at the end.

How we answer it at QueryNow

Our model is built around that question. We take one workflow at a time, at a fixed price. Before any work starts, the client signs written acceptance criteria that define what working means. We build in the client’s environment in two weeks, and the client pays $10,000 only after every criterion is met, with nothing upfront.

After that, the client owns the code and we leave. The leaving part matters as much as the price. A vendor that plans to stay has a reason to make itself necessary, while a client who owns the code and the criteria can run the workflow themselves or bring someone else in for the next one. You can see how the build is set up at querynow.com/build.

Questions that follow from the first one

Once you have asked the main question, a few follow-ups make the answer concrete. I would put all of these to any vendor, including us:

• Who writes the acceptance criteria, and when are they signed?
• What happens to the invoice if a criterion is not met?
• Whose environment is the system built in, and who holds the code and credentials at the end?
• How are change requests priced, and does a change reopen the criteria?
• What does the vendor’s involvement look like after the workflow is live?

A vendor who is paid on outcomes will usually answer these quickly, because the answers are already in its contract. Hesitation on the second question in particular is worth noticing. If nothing happens to the invoice when a criterion is missed, the acceptance criteria have no effect on what you pay.

Where this model does not fit

This model has limits, and I would rather say so plainly. It fits well-scoped workflows, where you can write down in advance what correct output looks like and test against it. Open-ended research, where nobody yet knows what the answer is, and larger platform programs need a different contract. For that kind of work, a time-based engagement with an honest vendor can be the right structure.

The question still helps there, even if the answer is “when the engagement continues.” A good vendor on a time-based contract should be able to tell you what it will deliver at each stage and how you will know it worked. If it cannot answer that, I would wait before signing.