How do I find the right piece of work for a software pilot?

Start by listing the components of your full project and asking which one delivers standalone value. A useful test: if the pilot is the only thing that ever gets built, would it still be worth having? If yes, it is a good pilot candidate. Avoid choosing a pilot that is so simple it does not reflect the real complexity of your full build.

Should I run a pilot with more than one team at the same time?

Commissioning parallel pilots on different pieces of work is theoretically possible but usually impractical for UK SMEs on limited budgets. A more realistic approach is to run one pilot, make a deliberate decision, and if the team does not pass, move to the next candidate with clearer criteria for what went wrong.

What if the development team refuses to do a paid pilot?

Some larger agencies will not take on small engagements below a minimum project size. That is not necessarily a red flag about quality, but it does mean they are not the right partner for a cautious first engagement. For de-risking purposes, look for teams that actively welcome smaller starting projects — they tend to be more confident in their work and more aligned with how UK SMEs actually buy software.

Can a pilot turn into the full project without a new contract?

Only if your original agreement specifically allows for it. More commonly, the pilot ends, you review the output, and then negotiate a separate statement of work for the full project. This is a feature, not a problem: the break point gives you a formal moment to re-evaluate scope, price, and team fit before committing further budget.

How is a paid pilot different from just asking for a detailed proposal?

A proposal tells you what a team thinks they will do. A pilot shows you what they actually do. Proposals are easy to make look good; working code is not. The pilot also tests communication, responsiveness, and how the team behaves under the modest pressure of a real deadline — none of which a written proposal can reveal.

How to Run a Software Pilot with an External Development Team

The safest way to trial an external development team is to commission a small, bounded piece of real work before signing up for a full project. This is called a software pilot (or paid discovery), and it gives you working code, a read on how the team communicates, and a clear signal of whether their quality matches their pitch — all for a fraction of the cost and risk of a full engagement.

Why a Software Pilot Matters (Especially If You Have Been Burned Before)

Many UK businesses that have worked with a software agency before have a version of the same story: the sales process was smooth, the proposal looked credible, but the delivered software was late, over budget, or simply did not work. The problem is almost never that the agency lied outright. It is that you had no way to test the reality of working with them before committing tens of thousands of pounds.

A structured pilot solves this by turning the question "can this team deliver?" from a matter of trust into a matter of evidence. You see how they scope, how they handle ambiguity, how they write code, and how they behave when something is harder than expected — before you are locked in.

What Makes a Good Pilot Project

A pilot is not a proof of concept built to impress you. It should be a real, useful piece of work that you actually need. That way the team is solving a genuine problem, not showing off under ideal conditions. Good pilots share these characteristics:

Bounded scope: It has a clear start and end. Not "build us a reporting dashboard" but "build a single-page report that pulls from our existing database and shows the three metrics our ops lead checks every Monday morning."
Representative complexity: It should touch the kind of problem your full project involves. If your main build will need third-party API integrations, include a small integration in the pilot.
Real delivery: The output should be deployed and usable, not a prototype that lives in a demo environment. You want to see how the team handles deployment, handover, and documentation.
Fixed price or clearly time-boxed: You need budget certainty to make the risk calculation work. A good team will scope a pilot tightly and hold to it.
Short enough to be honest: Two to four weeks is usually right. Long enough to reveal working patterns, short enough that both sides stay focused.

Tip

If a development team is reluctant to do a paid pilot and pushes straight to a full project contract, treat that as a red flag. Confident teams welcome the chance to demonstrate quality on a small piece of work.

How to Run a Software Pilot: Step by Step

Define the pilot brief before you talk to any team. Write down what the deliverable is, what "done" looks like, and what the success criteria are. Do this independently so you are not influenced by what a particular team says is easy or hard to build.
Share the brief with two or three teams and compare their responses. You are not just evaluating price. Look at how they ask questions, what assumptions they flag, and whether their scope interpretation matches yours. A team that immediately jumps to a fixed quote without asking clarifying questions is not one you want on a complex build.
Agree a fixed price and a written scope document. This does not need to be a lengthy legal contract, but it should specify deliverables, the number of revision cycles included, how out-of-scope requests will be handled, and who owns the code at the end. In the UK, code ownership defaults to the contractor unless you explicitly assign it — get this in writing.
Set up a simple communication rhythm from day one. A weekly written update (not just a call) forces the team to articulate progress and blockers in a format you can review later. Pay attention to whether updates are proactive or have to be chased.
Introduce a real complication mid-pilot. This sounds counterintuitive, but you will learn more about a team from how they handle a change in requirements or an unexpected technical constraint than from how they handle smooth sailing. Ask a reasonable question that slightly extends the scope and watch how they respond: do they problem-solve, or do they immediately escalate to extra costs?
Review the code, not just the output. If you have any technical resource in-house (even a part-time contractor), have them look at the codebase at the end. Is it readable? Is it documented? Is it the kind of thing your team could maintain or hand to someone else? Pretty front-ends can hide brittle architecture.
Do a structured retrospective before deciding on the full project. Ask the team what went well, what was harder than expected, and what they would do differently. How they answer tells you a lot about their honesty and self-awareness. Then make a deliberate go/no-go decision rather than drifting into the full project by default.

What a Pilot Should Cost

There is no universal figure, but a realistic software pilot for a UK SME typically involves one to three weeks of a small team's time. Day rates for experienced UK developers working at agency level vary considerably depending on seniority and specialisation. The point is not to find the cheapest pilot, but to find one priced honestly: a team that undercuts wildly to win the pilot is likely to make it back on the full project.

Think of the pilot fee as the cost of due diligence. A few thousand pounds spent validating a partner is a fraction of what you risk by committing a large budget to the wrong team.

Comparing Pilot Approaches: What to Look For

Signal	Green flag	Red flag
How they scope	Ask detailed questions, flag assumptions in writing	Quote immediately without clarifying the brief
Communication style	Proactive written updates, flag blockers early	Go quiet, respond only when chased
Handling a scope change	Discuss trade-offs, offer options	Immediately invoice for extras or refuse to engage
Code quality	Readable, documented, deployable	Spaghetti logic, no documentation, hard to hand over
Retrospective attitude	Honest about what was hard	Blame the brief, avoid accountability
Pricing	Fixed and held to	Vague, escalates mid-pilot

When a Pilot Is Not the Right Fit

Pilots work best when there is a genuinely separable piece of work within a larger project. If your project is highly interdependent from the start (for example, a complete platform rebuild with no usable components you can isolate), a full paid discovery phase is a better framing: the team documents your requirements, proposes an architecture, and produces a detailed scope for the build. This is still a bounded, paid engagement, and it still gives you the due diligence signal you need before committing to a build contract.

Note

Paid discovery is not a free quoting exercise. You are paying for a team's thinking, research, and architectural judgement — and you own the output regardless of whether you proceed with that team for the build.

Protecting Yourself Contractually in the UK

UK contract law does not automatically assign IP ownership to the client in a software project. If you commission a developer or agency as an independent contractor, the default position under the Copyright, Designs and Patents Act 1988 is that the creator owns the copyright unless your contract says otherwise. For any pilot or project engagement, make sure your agreement explicitly assigns all intellectual property rights, including source code, to your business on payment. Do not assume it is implied.

You should also confirm who owns any third-party libraries, frameworks, or tools the team uses, and whether any licensing obligations carry forward to you as the operator.