Hiring your first QA vendor as a startup

You run a small product team and you are hiring outside testing for the first time. There is no QA function to hand over to, the budget is tight, and the people who will manage the vendor are the same engineers who ship the product. You need testers who start quickly, work inside your tools, and can be let go cleanly if the arrangement does not fit.

What changes in criteria and weights

Named team, capacity and speed to start, onboarding, working in your tools, communication overlap, pricing transparency and the exit plan all rise to 5, and ownership of test code rises to 4. Formal test documentation, subcontracting and insurance drop to 2 and audit rights drop to 1, because a small team gains little from enterprise governance and a lot from getting the right people working in its tools this month.

Criteria whose weight differs from the default
Criterion	Default weight	Weight here
Named team and seniority mix	3	5
Capacity and speed to start	3	5
Onboarding plan and turnaround	3	5
Works in your tools	3	5
Communication and working-hours overlap	3	5
Pricing transparency	3	5
Exit plan and assistance	3	5
Ownership of test code and assets	3	4
Test strategy and documentation	3	2
Subcontracting transparency	3	2
Insurance and liability	3	2
Audit and information rights	3	1

Weights run from 0 (not scored) to 5. Every other criterion keeps its default weight of 3. The scoring template loads these weights when you choose this situation.

Which tools, in which order

Cost model: Compare a vendor against a first in-house hire with your own numbers before you talk to anyone, so you know which engagement model your budget can carry.

RFP generator: A short RFP with your stack, release rhythm and start date makes proposals comparable, even when you only invite a handful of vendors.

Vendor questionnaire: Filter the question bank by this situation so you ask about named people, start dates, tool access and exit rather than process certificates.

Proposal red-flag checker: Paste each proposal to catch generic staffing, hours with no outcome measures and test code kept in the vendor's repository.

Scoring template: Score shortlisted vendors with the startup weights so speed to start and pricing clarity count for more than polish.

Reference-call script: Ask references from similar small teams whether the people in the proposal were the people who started.

Contract clauses: Before signing, check that you own the test code, that the notice period is short, and that exit assistance is written down.

Typical mistakes

Choosing on the sales call instead of meeting the testers who will actually work on the product.

Letting the vendor host the test code, test cases and tool accounts, so leaving means starting from zero.

Signing a long minimum term to get a lower rate before the vendor has shipped a single release with you.

Nobody on your side owning the vendor, so questions wait days and the team drifts to low-value work.

Buying automation before the product has settled, then paying to rewrite scripts after every redesign.

Paying by the hour with no agreed measure of what a good week looks like.

Start with a pilot you can judge

A first vendor is an experiment. Frame the first weeks as a paid pilot on real releases, with named testers, a written scope and two or three measures you agree in advance, such as how quickly a build is tested and whether defects arrive with clear reproduction steps. Set a decision date. At that date you extend, adjust, or stop, and each option is already covered by the contract.

Keep the assets on your side

Create the repository, the test management space and the chat channels in your own accounts and invite the vendor in. Test cases, automation code and test data are paid for by you and are what you need if you change vendor later. In the US, code written by an outside company does not become yours by default, so the contract needs a written assignment.

Give the vendor an owner

Pick one person on your team who answers the vendor's questions, joins the daily check-in, and reviews what gets tested. Without that person, even a capable team ends up testing what is easy instead of what matters. Agree the hours when both sides are reachable and the channel for blocking questions.

Keep pricing plain

Ask for a rate per named person, what is included, how overtime and extra people are billed, and how rates change at renewal. A small budget is hurt more by surprise charges than by a slightly higher rate that is stated clearly. Enter each quote into the cost model so you compare the total over a year, not the headline rate.

Questions buyers ask

How small can a first engagement be?

Small enough that you can judge it quickly. One option is to start with one or two named testers on a paid pilot tied to real releases, then decide whether to extend. Put the pilot scope, success measures and the decision date in writing.

Do we need a test strategy document before we start?

Not a long one. Ask the vendor for a short plan that states what they will test first, how they report, and how they decide what to skip. Formal documentation matters more once you are regulated or larger.

Should the vendor build test automation straight away?

Only for the parts of the product that are stable. For fast-changing features, manual and exploratory testing usually gives feedback sooner. If automation is built, it must live in your repository and run in your pipeline.

What protects us if it does not work out?

A short notice period, test code and accounts held by you from day one, and a written exit clause that covers handover of test cases and knowledge. The contract tool lists these clauses with their rationale.