What a buyer already knows about us before the first email — and the five questions we answer in writing

By the time a founder writes to us, the decision is mostly made. Not in that email — in a chat window, weeks earlier, when someone asked a model who builds this kind of thing and got back a short list of names.

So we stopped treating the site as a brochure and started treating it as an answer sheet for a screening we do not attend. This is that answer sheet: the questions founders are now taught to screen an AI partner with, and what we say to each, in writing, before anyone asks.

The numbers, with their caveats attached

The figures a founder is likely to meet on this, as our sources report them.

95%    of deals won by a vendor already on the day-one shortlist,
       assembled before any contact
~2.5   vendors on the average shortlist, down from 3.2
94%    of B2B buyers using AI in the buying process
52% / 49% / 46%
       industry expertise / price / product fit, as the leading
       factor in final vendor selection
69%    of buyers who go to a human to validate what a model told them

provenance: the first four reach us through an agency's compilation of
            6sense, Forrester and Apollo research, not through the
            primary reports. We are repeating a repeat. The last figure
            reaches us separately, and we cannot name its source.

That provenance line is not decoration. In our experience, a compilation is where numbers drift quietly away from what the original study measured. What survives the drift is the shape, not the decimal — a short list, assembled early, without us in the room.

The number that changed how we write is the last one: buyers take what a model told them to a human to check. That is the test our writing faces. Not "does this read well", but "can a founder repeat this accurately to someone who will check it?" Our view, and it is only ours: a figure with a checkable source survives that call and an adjective does not. It is also why the answer to "what does this studio do" has to be identical everywhere a model can read it. Two different answers in two places is one answer that fails the check.

The screening is about failure, not capability

Here is the uncomfortable part for our category. The two buyer guides we read do not teach founders to ask what a partner can build. They teach them to ask what the partner got wrong.

what the two guides tell a founder to ask:

  how do you review and validate code generated by AI tools
      a strong answer is specific and process-driven;
      a weak one looks confused by the question

  name a technical decision you later regretted

  walk me through a project where you recommended against
  using AI for part of the workflow

  do you build for ownership transfer
      if they hesitate, walk away

  a pitch of "AI can do everything" is listed as a red flag,
  not as a selling point

caveat: both guides are vendor-authored. This is what buyers are being
        taught to ask — not a measurement of what buyers actually do.

Underneath those sits an objection passed to us first-hand. We set it down as our paraphrase, not anyone's words: to a technical buyer, an AI agency reads as a firm with no real track record in software development, project management or security. Unlike the quieter fear — that a supplier will fold — this one gets said out loud. A capability demo does not touch it.

Our answers

1. How do you review code a model generated? Not by asking the model that wrote it. Ask the author whether the work is good and the answer is always yes.

review loop, per change:

  a reviewer with none of the conversation's history reads the diff
  findings are fixed
  validation re-runs
  repeat

  exit only when ALL of these hold:
    - validation green
    - zero unresolved findings against the CURRENT state
    - the reviewer can summarise what the change actually does
    - test evidence exists, or a stated reason there is none

  refusals, enforced by a script rather than by asking nicely:
    - evidence may not shrink between passes
      (re-running only the fast check does not buy another pass)
    - an empty scope is not "reviewed" — a mistyped path cannot be closed
    - a validator that edited what it validated is evidence for nothing
    - a review the files have moved past is aborted, not recorded

2. Which technical decision did we later regret? Trusting a prompt as a control. The first version of that loop asked the model to respect the exit condition, and on a long instruction the model cut corners — it declared itself finished. The fix was not a better prompt. The exit condition moved out of the prompt and into a script that counts passes and compares diffs, because in our experience the rules that hold are the ones something other than the model enforces.

3. Where have we advised against AI? Wherever the same question has to return the same number twice. Our working line:

the model may write it        |  the model must not decide it
------------------------------|--------------------------------
  the wording                 |    the number
  the explanation             |    the schedule
  the draft                   |    the access rule
  the summary of a fact       |    whether the fact is true

A deterministic query owns the figure; the model narrates what the query already proved. That is a smaller product than "AI does the analysis", and it is the one that survives a client checking it on a Monday.

4. Do we build for ownership transfer? Yes, and the test is what ships alongside the code: an admin guide, a runbook, a written costs page, security notes, and a list of known issues we have not fixed. The last document proves the rest. In our experience, a handover with no known-issues page means somebody edited the list, not that the list was empty.

5. Can we actually ship software? This is the objection that gets said out loud. In our experience the only answer that lands is a system a person can open: live products, reachable URLs, and a straight account of how failures are caught and rolled back. We stopped opening with a capability demo — that was the thing we cut. It answers a question nobody in this screening is asking.

What would change our mind

If the figures above turn out to be an artefact of the compilation — if the primary reports say something materially different — the argument for publishing our failures in advance weakens considerably, and we will say so here at the same length. What would not change: the screening questions are answerable in writing today, at no cost, whether or not 95% is the right number.

FAQ

Is this just SEO for chatbots? No, and our view is that treating it that way is the failure mode. Copy written to be scraped tends not to survive the human check that follows, because there is nothing behind it to verify.

We are small and pre-revenue. Does the shortlist logic apply? The reported shortlist is around 2.5 vendors, and industry expertise (52%) outranks price (49%) in final selection. Our read: a small studio cannot outspend anyone on that list, but a specific, checkable answer to a screening question is not a budget item.

Do you publish failures from client work? Not client failures — ours. The regret above is about our own tooling. Anything belonging to a client stays with the client.

What if a buyer never asks these questions? Then they were answered anyway, in the material a model reads months before the first call. That is the whole reason to write them down.

Where to read the long version

We are working through the same five questions one product at a time — the trade-offs, the numbers, and the parts we cut. Cases and process at iloblique.com.