Paid Trial Projects vs Free Tests: What Works When Hiring a Developer

A paid trial project is the most reliable way I know to vet a developer before you sign up for something bigger, as long as it's short, clearly scoped and close to the work you'll actually do together. Free take-home tests look cheaper, but they mostly tell you who has spare evenings, not who will deliver your project.

I sell a fixed-price discovery sprint myself, so weigh my advice with that in mind. I'll also cover when a trial is a waste of time and money for both sides.

The short answer: which kind of trial fits your situation

My rule of thumb: building something new? Start with a discovery sprint. Already have a live system? Start with a small paid task or a code review. A free test is rarely the right answer.

The trial is one step in a longer hiring process. The rest, from defining what you need to signing a contract, is in my complete guide to hiring a developer.

Why free take-home tests rarely work

Unpaid tests feel like a cheap way to reduce risk. In practice they often give you a worse basis for choosing than no test at all, for four reasons.

The strongest candidates say no. A freelancer or contractor with a full calendar can't give away an evening to a client who may pick someone else. So you end up testing the people with the most time, not the best people.

The test measures the wrong thing. Most take-home tests are small and isolated: a toy app from scratch or a coding puzzle. That shows whether someone can code. It doesn't show whether they can work inside your existing system with your half-formed requirements, which is where projects actually go wrong.

The effort is lopsided. Either the developer spends two hours and sends something quick, and you've learned very little. Or they spend three unpaid days, and you've effectively selected for whoever can afford to work for free.

Ownership gets murky. If the "test" is a real piece of your product, you're getting work without a contract. In many countries, Denmark included, a contractor generally keeps the rights to what they write unless you agree otherwise in writing (this isn't legal advice, so check the rules where you are). Either way, it's a gray area neither of you wants.

There is one kind of free evaluation I think is fair: a call where the developer asks about your project and walks you through how they'd approach it. That's not a trial. It's a normal part of preparing a quote. If you've heard how someone thinks and seen their past work, you already have a lot to go on. If you can't read code yourself, my guide on how to evaluate a developer as a non-technical buyer shows what to look for.

What a paid trial shows you that an interview can't

An interview tells you whether you can talk to each other. A paid trial tells you what it's like to work together, and those are different things. It's the same reason some companies build paid trials into their hiring. Automattic, the company behind WordPress.com, includes a paid trial on real tasks as a standard step in its hiring process.

The logic holds when you're hiring a freelance developer for a project. During the trial, watch for these:

• The questions they ask before starting. A good developer asks about goals, users and what's out of scope. No questions at all is a warning sign.
• The shape of the estimate. Do you get a range with the main unknowns named, or a single number with no caveats?
• Whether you hear from them without chasing, including when something takes longer than planned.
• What happens when you change something mid-way. Do they tell you what it costs in time, or does it quietly disappear into the hours?
• What the handover looks like. Is the code in your own repository, with a short note on what was done, how it was tested and what was deliberately left out?
• Whether they push back. A developer who suggests a simpler option or says no to a bad idea is worth more than one who agrees to everything.

None of that shows up in a CV or a technical interview. It's also what decides whether a six-month project stays on budget.

The discovery sprint: the trial I recommend for new builds

If you're about to build something new, such as a customer portal, a SaaS product or an internal tool, a paid discovery sprint is in my view the best trial you can run. It's a short, fixed-price engagement where you and the developer work out what should be built before anyone writes production code.

A discovery sprint typically ends with:

• a description of goals, users and the core workflows
• a prioritized feature list for the first version, and what can wait
• a technical plan: which systems it needs to talk to, where data lives and how it will be hosted (including whether it stays in the EU, if GDPR matters to you)
• the biggest risks, such as a third-party integration with thin documentation
• an estimate per phase that you can actually budget against

If one technical unknown could sink the project, the sprint can also include a small prototype that tests exactly that. You find out whether it's feasible before the budget is set.

Two things make this a good trial. It's useful whatever you decide next, because you end up with a plan another developer could build from, provided you own it. And you see exactly what you need to judge: how the developer asks questions, prioritizes, weighs risk and writes things down. Those are the same qualities that decide whether the rest of the project holds together.

I start larger builds with a fixed-price discovery sprint, and in the build that follows, the client owns the code from day one. What a sprint like that usually costs, and why it tends to pay for itself, is covered in my breakdown of discovery phase costs.

How to scope a paid trial project in six steps

These steps apply to all three paid options: the discovery sprint, the small task and the code review. None of them require technical knowledge.

1. Pick work you'd pay for anyway

The best trial is work you need regardless of who does it. If you have a live product, choose a task from your backlog that can be finished in a few days and signed off by one person: a new export, an integration with a documented API, or a handful of bug fixes. My guide to hiring a developer for a small project covers how to scope that kind of task.

Avoid exercises invented for the occasion. Nobody puts real effort into them, and the result ends up in a drawer.

2. Fix the time and the budget

Agree on a fixed fee or an hourly rate with a hard cap, plus an end date. A trial should wrap up within a couple of weeks of calendar time. If it drags on longer, it's no longer a trial but the start of the project.

The math is simple: hours times rate. At an example rate of €100 an hour excluding VAT, 15 hours comes to €1,500 and 40 hours to €4,000. That's a worked example, not a market rate. If the developer quotes a day rate, three to five days is a sensible trial size. Compare the figure to the project ahead of you: a small slice of the budget to test the working relationship is cheap insurance.

3. Write down what you'll judge before you start

Choose three to five criteria, for example the quality of their questions, whether the estimate held, how often you heard from them unprompted and how usable the handover was. Writing them down in advance makes you judge on what matters rather than on whether you liked the person.

Feel free to tell the developer what you're looking for. That's not cheating. It's how a real engagement works too.

4. Put the deliverable and ownership in writing

State what you'll get: a document, code in your own repository, a status note. State that you own what's produced and can use it with another developer. A one-page agreement is enough for a trial, but it needs to exist. For the full contract later, use my freelance developer contract checklist.

Think twice before giving a trial developer access to real customer data. Use test data wherever you can. If they will process personal data on your behalf, GDPR generally requires a data processing agreement, even for a short trial.

5. Work together the way you would in the real project

Use the same contact person, the same channel and the same meeting rhythm you expect later. Someone on your side should be able to answer questions within a day. If you're hiring across borders, this is also where you find out whether time zones work in practice: a developer in Central Europe overlaps almost fully with UK and EU office hours and only for a few hours with the US East Coast. And don't hover over every step. You're paying to find out whether they can work independently.

6. Hold a short debrief and decide quickly

Finish with a half-hour call to go through the result, and ask what they'd do differently in a full project. Decide within a week or two, and say so honestly if you go with someone else. A good developer has planned around your trial, and a quick answer is basic courtesy.

When you can skip the trial

A trial isn't always the best use of your money. Skip it or shrink it in these situations:

• The whole job is small. If the project is 20-30 hours, the job itself is the trial. Adding a separate one just makes it more expensive.
• You have strong references from someone you trust who had something similar built. That often tells you more than a trial. Ask the right reference check questions to get the most out of the call.
• Your system is down right now. An outage is no time for a trial. Call whoever knows the system, and look for a new developer once things are stable.
• You're thinking of trialing five developers at once. Paying five people is expensive, and you can't follow five trials properly. Shortlist one or two using past work, references and a call, then trial only them.
• You have no budget for a paid trial. That's a sign the project needs to shrink before it starts, not that the trial should be free.

One honest limit on my side: I work with Laravel, PHP and JavaScript (React and Next.js). If your system is built on something else, a trial with me would be an expensive learning exercise paid for by you. You're better off with a developer who already knows that stack.

Next steps

Run through this list before you start a trial with any developer. It makes sure you get an answer you can use, even if the engagement doesn't continue.

If you want to see how I price discovery sprints and the work that follows, it's all on my pricing page. Still looking for candidates? Find one or two first, then come back here with your shortlist.

Frequently asked questions

Should I pay a developer's full rate for a trial project?+

Yes, as a rule. A trial is real work, and a developer who heavily discounts it has to recover the money somewhere else. What matters isn't the hourly rate but a fixed frame, so you know the maximum cost up front. If you want to spend less, make the trial smaller rather than pushing the rate down.

What if the paid trial goes badly?+

Then it did its job: you found out for a small fee instead of halfway through a large project. Pay as agreed, get whatever was done handed over with a short status note, and tell the developer briefly why you're not continuing. If the work was useful on its own, another developer can pick it up from there.

Can I take a discovery sprint from one developer to another?+

Yes, if your agreement says you own the output. That's one of the main reasons to choose a discovery sprint as your trial. Ask before you sign, because some developers and agencies keep the rights to their plans and estimates. A plan you can't use elsewhere ties you to whoever wrote it.

What if a developer refuses to do a trial?+

If they turn down a free test, that's completely normal. Ask whether they'd take a small paid task or a discovery sprint instead. If they also refuse any scoped, paid start, ask why. It may simply be capacity, but it can also mean they only want to lock you into a large engagement from day one.

Can't a developer just use AI to pass a take-home test?+

Often, yes, and that's another reason to drop small coding tests. An isolated exercise can now be solved quickly with AI tools, so the result says little about the person. It's much harder to fake your way through a trial where the developer has to ask questions, estimate, work in your existing code and explain their choices. Ask how they use AI in their work.