Services How we work Industries Work About Blog Book a call

Questions to ask an AI development company, with our answers

The standard vendor-vetting checklist, plus the 2026 questions incumbents miss, plus our own answers, on the record, including the weak ones.

AskQuorum AI · · 4 min read

Every AI development company's site has a page telling you what to look for in a vendor. Ours does too, and you're on it. The twist we haven't seen anyone else run: publishing our own answers to the checklist, on the record, including the two where our honest answer is a weakness rather than a selling point.

A vendor who scores itself perfectly on its own checklist is grading its own homework. This is not that.

The standard checklist, and what a weak answer looks like

Across the vendor-vetting guidance we could find, six questions come up consistently as the ones that separate a real evaluation from a sales conversation.

Ask thisA weak answer sounds like
Show me evidence of shipped production systems, not demos"We have case studies available on request" (and never sends them)
Will named engineers work in my environment, or account managers?"You'll have a dedicated team" (unnamed, unspecified)
When do I see working software, days or months?"After the discovery phase" (undated)
What is the path from prototype to production, concretely?"We'll cross that bridge when we get there"
What are your explicit answers on compliance and risk?Silence, or a generic security-page link with no specifics
Who owns the code, and is that assignment present-tense?"That's covered in our standard contract" (unquoted)

Our answers

Evidence of shipped systems. See our case studies. Real engagements described with enough specificity to evaluate the work, not a client-logo wall.

Named engineers. Yes. Our engagement models describe a dedicated team you can name and evaluate individually, not a rotating pool represented by one account manager.

Time to working software. Weeks, not months, inside a defined thirteen-phase process with demo checkpoints built in rather than a single reveal at the end.

Prototype-to-production path. Explicit, and it is the subject of its own post if you're evaluating an AI-tool-generated prototype specifically: see what production-readiness actually requires.

Compliance and risk. Full IP transfer and NDA-first engagement is written into every contract, and our own conversational product is built to the EU AI Act's Article 50 disclosure requirements. See our breakdown of what that actually requires.

Code ownership. Present-tense assignment language: "hereby assigns," not "agrees to assign." We wrote an entire post on exactly why that distinction matters, because most vendors get this one vague on purpose: who owns the code your agency's AI wrote.

The two questions incumbent checklists miss

Every checklist above predates 2026 in spirit even where it's freshly published. Two questions are specific to this moment and we haven't seen either on a competitor's list yet.

"How do you use AI in your own delivery, and do I pay for the time it saved?" If a vendor's engineers use AI tooling to move faster (and most serious ones do by now), a time-and-materials invoice that doesn't reflect that is a transparency problem. Our answer: yes, we use AI extensively in our own delivery process, and our pricing reflects that rather than billing full manual-speed hours for AI-accelerated work.

"Is your conversational or generative product Article 50 compliant?" Most vendors building chatbots or generative features for clients haven't internalised that the EU AI Act's transparency obligations apply to what they ship, not just to what they are as a company. Ours is: we run our own compliant multilingual assistant, so we know exactly what the obligation requires because we had to meet it ourselves.

Where we're honest about being weak

Two questions on the standard checklist, we don't score well on, and saying so is the point of publishing this at all:

Named enterprise clients. We don't publish a client-logo wall. Some of that is NDA-first engagement structure; some of it is simply company size. If a recognisable-name reference is a hard requirement for your evaluation, say so early rather than discovering it's missing later.

Published outcome metrics. We don't have a "40% faster time-to-market" statistic to hand you, because we're not going to publish a number we can't stand behind with real data. What we offer instead is the work itself, described specifically enough to evaluate on its own terms. See the case studies linked above and judge the specificity, not a headline number.

Ask us these yourself

A checklist with pre-written answers is still just a checklist. The actual test is whether the answers hold up when you ask them directly, with follow-up questions, to an engineer rather than an account manager. Thirty minutes, no deck. Ask us.

If your evaluation is a formal one rather than a conversation, these six questions belong in the document itself, where every vendor has to answer them in writing and on the record. Our software development RFP template carries them, along with the AI-usage disclosure and code-ownership sections most 2026 templates still leave out.

Common questions

Who owns the code, in writing, with present-tense assignment language, not "we'll figure that out in the contract." It is the question incumbent checklists list as the biggest red flag when a vendor can't answer it cleanly, and it's the one most often left vague.

Yes, and ask the follow-up: do you pay for the time AI saved? A vendor billing time-and-materials for work substantially accelerated by AI tooling without disclosing that is a pricing-transparency problem worth surfacing before you sign, not after the first invoice.

Be more skeptical, not less. A vendor with zero weaknesses on a self-scored checklist is grading its own homework. Look for a vendor that names its actual limitations plainly. That is a stronger signal of honesty than a clean sheet.

Not automatically. NDA-first engagements, common in AI development for competitive-sensitivity reasons, often prevent naming clients. It becomes a real red flag only when it's paired with no evidence at all: no case studies, no described engagements, no way to verify capability through any channel.

Ask us these yourself

Thirty minutes, no deck, an engineer answers, not a salesperson reading from this page.