Checking whether a vendor's client-stage experience fits yours

A vendor that says it works with companies at your stage is making a claim a profile can support with evidence or leave unconfirmed. The catalog records the stage of the clients a vendor has actually served as one field, separate from a further assessment of which stage a vendor is judged to fit, and the difference between the two decides what a buyer can rely on before a first call. This page sets out what changes in the work itself as a client moves from one stage to another, the two fields on a profile where a stage mismatch surfaces first, what to ask a vendor whose record sits at only one stage, and what a blank stage field is and is not telling a reader.

What changes in the work between an early client and an established one

A vendor testing a product for a company before it has found product-market fit is working without two things a vendor testing for an established organisation can usually assume: a written set of requirements to test against, and a regression suite built up over a previous release cycle. A team of testers builds both of those artifacts as it goes, alongside the testing itself, which is a wider scope than executing checks against material that already exists. A company adding headcount and shipping releases more often at the same time changes what a vendor has to track, since the target for testing keeps moving between sprints instead of holding still for the length of an engagement. An organisation running a formal purchasing process adds steps a vendor has to clear before testing starts at all: a procurement cycle, a security review of the vendor itself, and a release window the finished work has to land inside rather than a date the vendor proposes. A buyer purchasing testing on behalf of its own client adds a further layer again, since the requirements, the release date, and the sign-off on the finished work can belong to a party the testing vendor never speaks with directly.

Two profile fields where a stage mismatch shows up first

Two fields on a profile surface a stage mismatch before any other part of the listing does. One field states the minimum size of engagement a vendor accepts, in dollar terms; a vendor whose listed minimum sits far above what an early-stage budget can carry is a poor match regardless of what the rest of the profile says about who it has served before. The other field states the number of days a vendor needs before a team can start work; a period built around clearing a large organisation's security review is a different commitment than a period built around starting the week a contract is signed, and a buyer working against a tight release date needs to know which one is being read. Both figures are self-reported by the vendor and recorded together with the source they were read from, and a mismatch on either one is worth raising in the first message, before a proposal has been priced.

A served-client record and a fit assessment are two separate lines

A profile carries two different statements about stage, and treating them as one turns an observation into a verdict. One line lists the stages of client a vendor has actually served, drawn from cases and disclosures on file; it states who the vendor has worked with. A separate assessment sits elsewhere on the same profile, checked against a fixed set of conditions unrelated to that served-client list and described in full on the methodology page; it states which stage of buyer the vendor is judged to suit. A vendor can show a served-client history at one stage while carrying no separate fit assessment for it, because the two lines draw on different evidence and answer different questions, and neither one stands in for the other.

Two questions for a vendor whose record sits at only one stage

A vendor whose served-client history sits entirely at one stage is not automatically unable to work at another one, and two direct questions test whether that prior experience actually carries over. First, ask for a specific instance where the vendor adjusted its process for a client at the stage now being considered, such as building a regression suite from nothing for a company that had none, or preparing for a security review it had not gone through before. A vendor that has done adjacent work names the instance; a vendor that has not describes the adjustment only in general terms. Second, ask who inside the vendor's own team has led an engagement at the new stage before, by name and by role, rather than asking whether the company as a whole is capable of it, since a company-level answer can describe capacity nobody on the assigned team has actually exercised.

When the buyer is an agency and the client sits one step further away

An agency buying testing on behalf of its own client needs three questions settled before work starts, because the party that receives the result and the party that accepts it are not guaranteed to be the same one. Ask who receives the test report: the agency, the agency's client, or both, and in what format. Ask who signs the acceptance that closes out the engagement, since an agency accepting on its client's behalf is taking on a liability its own contract with that client may or may not cover. Ask whether the testing vendor can be named directly in correspondence the agency sends to its own client, since some agencies resell the work under their own name and keep the vendor behind it undisclosed. Each of these three questions is worth settling in writing before the first test cycle runs.

What a blank client-stage field is and is not telling you

An empty field for served client stages means no case or profile disclosure has confirmed a stage for that vendor, not that the vendor has never worked with a company at that stage. The absence carries no direction on its own: it does not rule a candidate in for a stage, and it does not rule a candidate out either. A buyer who finds the field empty for the stage that matters sends the same two questions from the section above directly to the vendor, and treats an answer that names a specific engagement or a specific person the way a populated field would have been treated to begin with.

Matching the stage claim to a shortlist decision

The checks above turn a phrase like "we work with companies your size" into facts that can be requested from a vendor directly: the served-client history behind the claim, the two profile fields where a mismatch shows first, and, where that history sits at only one stage, a specific instance of the adjustment now being asked for. A shortlist built around a company still working toward product-market fit can start from the vendors listed under Startups, and a shortlist built around an organisation running a formal procurement and security review process can start from the vendors listed under Enterprises. Ranking pages for the other two stages on this axis are not published yet, because neither group currently carries enough confirmed profiles behind it to support one. Whichever list a shortlist starts from, the same two profile fields and the same two questions apply again to each candidate before a contract moves forward.