A pilot is the only part of vendor selection that produces evidence rather than impressions. Everything before it, from the deck to the case studies to the technical call, is the vendor at their most prepared. Two weeks of real work in your real codebase is the first time you see them on an ordinary day. It is worth paying for, and the paying is the part that makes it work.
The short version
Pay for it. A free trial is staffed with whoever is on the bench, because nobody assigns their best engineer to unpaid work.
Use a real ticket from your actual backlog, not a sample project. Sample projects test nothing you care about.
Agree the exit criteria in writing before the first day, including what happens if you stop.
You should keep the merged code either way, and the fee should be refunded if you do not continue.
What you are testing is the process, not the output. Two weeks is too short to judge output and exactly right to judge how someone works.
Why paid, specifically
Free trials are common and they are worse than useless, because they produce confident conclusions from bad evidence. The mechanism is simple: a vendor staffs unpaid work with whoever is not currently billing. That is, by definition, the engineer nobody else wanted this month. You then evaluate the vendor on their weakest available person and either reject a good vendor or, worse, accept and get someone different.
Paying changes the incentive completely. A paid pilot is a small engagement, and vendors staff small engagements with people they hope will win the large one. It also lets you ask for a named engineer and to be told if that person changes, which is a reasonable request when money has changed hands and an awkward one when it has not.
Where our interests differ from yours
We want the pilot fee. You want the option to walk away. Resolve it by agreeing up front that the fee is refunded if you do not continue, and that you keep the merged code either way. Any vendor unwilling to write that down is telling you something useful for free.
A pilot is the step after the shortlist. Building that shortlist is what the eleven questions are for.
What to put in it
The instinct is to pick something small and safe. Resist it. A trivially easy ticket tells you nothing, because everyone passes. Pick something that a competent engineer would find moderately annoying.
-
01
Pick a real ticket, not a sample project
Something from your actual backlog that touches your real codebase, your real API and your real deployment pipeline. Sample projects test nothing you care about.
-
02
Choose something with a hidden edge case
The best pilot tickets look simple and are not. What you want to observe is whether they discover the complication and raise it, or ship past it silently.
-
03
Agree the exit criteria in writing first
Merged to main, tests passing, reviewed by your senior developer, deployed to staging. Written down before day one, not negotiated on day nine.
-
04
Give repository access on day one
If an external contributor cannot be in your repository on the first morning, the pilot is measuring your onboarding rather than their engineering.
-
05
Name one reviewer with a 24 hour target
A PR sitting from Friday to Tuesday costs three days of a fourteen day pilot, and the vendor will reasonably point that out afterwards.
Repository access on day one is also the first line of a good onboarding week, described in how to hire React developers.
What to measure, and what to ignore
Two weeks is far too short to judge throughput, and any conclusion you draw about speed will be noise. What two weeks measures very well is how somebody behaves when they meet something unexpected.
"You are not buying two weeks of output. You are buying evidence about the next six months, and the most predictive thing in the sample is what happened when they got stuck."
Signals worth acting on in week one
If you see these, do not wait until day fourteen to draw the conclusion. They do not improve with familiarity.
A reviewer who responds within a day is the same requirement that makes overlap hours worth paying for.
The terms to agree before day one
The second line is the one that matters and the one most vendors will accept if asked. It converts the pilot from a purchase into an option, which is what makes it possible for you to be honest about the outcome rather than talking yourself into continuing because you have already spent the money.
Refundable fee, IP on payment and a named engineer are contract terms, and the contract checklist covers the rest of them.
Deciding afterwards, including the awkward case
Most pilots end clearly. The uncomfortable ones end with a competent engineer, an unremarkable outcome and no obvious reason to say no, which is exactly when the sunk cost starts arguing on the vendor's behalf. Decide against a rubric you wrote before you knew the answer.
The second row is worth dwelling on because it is routinely scored wrong. A pilot that runs over because the ticket concealed a genuine problem, and where that was surfaced on day four rather than day thirteen, is a strong result. Penalising it teaches every vendor you work with to hide bad news until the last possible moment, which is a lesson you will pay for repeatedly.
If you are continuing, do two things immediately: name the same engineer in the statement of work, and write down what the pilot taught you about your own side. Almost every pilot exposes something about the client: a slow reviewer, an undocumented deployment, a ticket-writing habit. That finding has a longer shelf life than anything you learned about the vendor.
Questions people ask
Where to go next
The pilot comes after the shortlist. To build one, use the eleven questions that sort vendors in one call. Before the first invoice, the contract checklist covers the IP clause the pilot needs. Our own pilot terms are stated on the hire React developers page.
Yogesh Jadhav
Founder of reactdevstudio. Ten years as a working full stack developer, across SaaS products and client work.
Related, Group A only
Three more on offshore work
Procurement and process posts only, scored within Group A, so a buyer is never handed a React internals piece.