Paid Trial Project for Developers: Scope, Pay, Scorecard

A paid trial project is the cheapest way to find out whether a developer can work with your team before you sign a long contract. You give them a real, bounded piece of your backlog, pay them their normal rate, and watch how they communicate, estimate, ask questions and take feedback. Done well it costs a few thousand dollars. A wrong hire costs far more.

The idea is not new, but most teams run it badly: the task is vague, the pay is a discount, and the verdict is a gut feeling. Here is a version that holds up.

What a paid trial project is (and isn’t)

A trial is a time-boxed, contracted engagement on real work. It is not a puzzle, and it is not free labour with a promise attached.

Codersera, a developer-matching vendor, defines the short version as one to two weeks, and says that is the standard length for a short-sprint trial. Longer arrangements exist (it lists contract-to-hire at one to six months), but those are a different decision with different legal terms.

Format	What it tests	Typical length	Pay
Live coding	Problem solving under observation	1-2 hours	None
Take-home	One narrow problem, solo	2-6 hours	Ideally paid
Paid trial project	Working inside your codebase and process	1-2 weeks, 20-40 hours	Full prorated rate
Contract-to-hire	Long-term fit	1-6 months	Full rate

Our guide to take-home tests versus live coding covers the first two rows. The trial is what you run after those have narrowed the field to one or two people.

How to scope a paid trial project

Codersera’s guidance on scope is the most concrete available, and it matches common sense: pick a task from your real backlog, size it at 20 to 40 hours, and make sure a new team member could solve it with the context they would reasonably have. Four rules follow.

Real, but not on the critical path. If the next sprint depends on the result, you will grade the deadline instead of the developer. Pick something you would like done, and could live without for a month.

Self-contained. A good trial ticket touches one module, has a clear definition of done, and does not need three days of archaeology in a legacy service. A bug cluster, a small feature behind a flag, a test-coverage push on one package, or an API integration all work.

Written down. Give the developer a one-page scope document with the goal, the acceptance criteria, the repo access they will get, and who they can ask. If the brief is ambiguous, that is information too, but only if you wrote it down so you can tell whether they asked about the right gaps.

One point of contact. Assign a named person who answers questions within a working day. A trial where the developer waits three days for a reply measures your responsiveness, not theirs.

Paying for the trial

Pay it. Pay the rate you would pay if they were hired, prorated to the hours.

An unpaid trial screens out exactly the candidates you want, the ones with other offers and the experience to know better. It also raises a legal problem: unpaid work for a company with no contract is how disputes over ownership and wages start. Put a short contract in place before the first commit. It should cover payment terms, who owns the code if you part ways, confidentiality, and what happens to repo access afterward. Contract basics are in fixed price versus time and materials, and a trial is almost always time and materials.

The arithmetic is simple. At a hypothetical $60 an hour, 30 hours is $1,800. Codersera’s worked example prices a two-week trial at $4,600 and adds about $1,000 of team bandwidth for onboarding and review, around $5,600 in all. Count your own time: someone senior will spend hours on onboarding, questions and code review. For what the engagement behind the trial typically costs, see what it costs to hire a developer in 2026.

Vendor programs show the other end of the range. Lemon.io’s documentation describes a four-week trial of up to 160 hours in which the developer is paid from day one. That is a lot more commitment than most teams need to make a decision.

Scoring a trial: five things to grade

Code quality is the part everybody checks. It is also the part your interviews already measured. Codersera lists five dimensions, and the other four are why the trial exists.

1. Code quality. Does it pass review without a rewrite? Are there tests that fail when the behaviour breaks?
2. Communication. Did they post updates unprompted? Did the first message after kickoff contain questions, or silence?
3. Reliability. Did the work land when they said it would? Did they flag slippage early?
4. Autonomy. Did they unblock themselves, or wait for instructions on every decision?
5. Attitude toward feedback. What happened after the first review comment? Defensiveness on day three predicts the next six months.

Write a one-to-five score for each before the trial starts, with a sentence describing what a three looks like. Scoring afterwards, against criteria invented after the fact, lets the last impression decide. If you already use a rubric from screening developers beyond LeetCode, reuse its categories so interview and trial scores can be compared.

Check in twice

Schedule a short call at the end of day two and another at the end of the first week. The first catches setup problems you caused. The second is where you hear how they feel the work is going, which you can compare to what you see in the pull requests.

Ending a trial fairly

Commit to a decision date. Codersera suggests giving feedback within three business days of the trial’s end, which is a reasonable standard. A developer who delivered a week of good work and then heard nothing for a month will not take your next call.

If you are continuing, move straight into onboarding. The first 30 days of onboarding a developer is where the context from the trial carries over. If you are not, pay the invoice promptly, say specifically what was missing, and confirm that repo access is closed.

When not to run one

Skip the trial when the role is a few days of well-understood work, where a reference check and a portfolio are enough. Skip it when your codebase cannot be shared before a long contract is signed. And skip it when you cannot name a person who will review the work, because an unreviewed trial is a very expensive coin flip.

The short version

Choose a real, non-urgent ticket of 20-40 hours. Write the scope on one page. Sign a short contract. Pay the prorated rate. Score five dimensions against criteria you set in advance. Tell them your decision within three business days. If you would rather have a vetted shortlist before you reach the trial stage, CoderCops for companies covers how that works.