Five questions to ask before you sign with an agency

Hiring an agency is often the right call. You get a team on Monday instead of a hiring process that runs until Christmas, and people who have shipped this shape of thing before and will not learn it on your money. This guide is not an argument against it.

But there is an asymmetry in the room. The agency has signed this contract a hundred times; you are signing it once, possibly ever. They know exactly which clauses matter and where the ambiguity sits, because the ambiguity is usually there on purpose — not maliciously, just commercially. Silence in a contract always resolves in favour of the party who wrote it.

The fix is not to become a lawyer. Five questions, asked out loud before you sign, remove almost all of the risk founders actually get hurt by. A good agency answers each in a sentence. A poor one needs to schedule a meeting.

1. Who owns the code — and can you point at the clause that says so?

Start here, before you look at the price. Under UK law, ownership does not follow the money. The Copyright, Designs and Patents Act 1988 makes the author of a work the first owner of the copyright in it. The exception for employees creating work in the course of employment hands ownership to their employer — the agency — and does not reach through to you. Section 90 is unambiguous: an assignment of copyright is not effective unless it is in writing and signed by the person giving up the rights.

So look for two things. First, active assignment language — "the Supplier hereby assigns" rather than "grants a licence to use". Second, clarity on what the agency is keeping back. That part is legitimate: most agencies have accumulated their own frameworks and deployment tooling over years and will not hand you exclusive rights to their toolkit for one project fee. What is not reasonable is leaving it vague. Ask for the retained items to be listed by name, and for your licence to use them to be perpetual, irrevocable, worldwide and transferable.

Transferable matters most and is missing most often: a non-transferable licence means that when you are acquired, the buyer's lawyers find a component of your product that cannot legally travel with the sale. And if the agency uses subcontractors, make sure their assignments flow through — an agency cannot give you rights it never acquired.

2. How am I being charged, and is that the right model for where I am?

Fixed price, day rate and retainer are all legitimate. The mistake is choosing the model that suits the agency's cash flow rather than your stage of certainty. Fixed price transfers cost risk to the agency, but only if the specification is nailed down first — and at pre-seed it never is, so the change-request process quietly becomes the real pricing model. Day rate handles genuine uncertainty far better, but all budget risk sits with you, and without someone who can judge whether the work is moving at a reasonable pace it is an open tab. Retainers buy guaranteed capacity at a lower effective rate than ad-hoc work, with a symmetrical catch: you pay whether or not you have work ready.

Whichever you pick, benchmark it. UK agency day rates in 2026 run roughly £250–£350 for a junior developer, £400–£550 for mid-level, £550–£750 for a senior developer and £600–£900 for a technical architect or lead, with London typically adding a 10–20% premium. Divide any fixed price by those numbers and you can see what team size and duration the agency has actually assumed. If the implied team looks impossibly small for the scope, the change requests are already priced in — they just have not been written down yet. For most early companies, milestone-based fixed price for the initial build moving to a retainer once there is a live product works well.

3. Can I see the repository — today?

Ask to be added to the repository during the sales process, before any money moves. The reaction tells you more than any reference call. A default develops on almost every project unless someone prevents it: the code lives in the agency's GitHub organisation, the cloud account is on the agency's billing, the domain is registered to whoever set it up, and the monitoring and CI pipeline sit under agency logins. Nothing sinister has happened — it is the fastest way to start, and clients rarely ask. The consequence appears only when you need it to be otherwise, at which point even a friendly separation becomes a two-week archaeology project. The remedy costs an afternoon: your own organisation, your own cloud account, your own domain, and the agency invited in as collaborators.

While you are in there, ask what is actually in the code. In 2026, 68% of audited codebases contained open-source licence conflicts, up from 56% a year earlier, across 947 codebases in 17 industries. Most software is other people's software, and a copyleft licence in the wrong place can constrain how you commercialise your own product. Ask for a list of open-source dependencies and their licences, plus every paid third-party service the product relies on. Ask about AI too, because your agency is using it: the same research found 76% of organisations check AI-generated code for security risks but only 54% evaluate it for IP and licensing risk.

4. Who exactly is working on this, and what happens when they leave?

Agencies sell with their strongest people; every services business does. The question is whether those people are still on your project in month four, or have been rotated onto the next pitch and replaced by someone learning your domain at your expense. The mechanism is a key personnel clause: it names the individuals essential to the work, says they cannot be substituted without your written approval, and requires any replacement to be of equivalent calibre. Agencies push back on how tightly it is drawn, not on whether it should exist.

The subtler version of the risk is knowledge concentration: even with named people, one person understands your system and nobody has written any of it down. Guard against that with an ongoing obligation rather than a one-off deliverable — documentation, environment setup and deployment runbooks kept current as a condition of each milestone. State the test in the contract: a competent engineer who has never seen this project should be able to run and deploy it from the written documentation alone.

5. What does it cost to leave — and what does "maintenance" actually mean?

These are two questions, but they fail together. "Maintenance" is one of the most expensive undefined words in software contracts. To an agency it means keeping the lights on: security patches, dependency updates, bug fixes, minor tweaks. To a founder it very often means "they will keep improving it", and the gap becomes a monthly argument. In the UK, ongoing maintenance typically budgets at 15–25% of the original build cost per year — on a £120,000 build, £18,000 to £30,000 annually, so it is not a rounding error. Make the definition concrete: what response time applies to a critical bug, are security patches included or extra, how many hours of small changes per month, and is a major framework upgrade maintenance or a project?

Then price the exit. Handover should be a deliverable with a scope and a number attached: full source code and commit history, administrative access to every repository and environment, all credentials and third-party accounts, design files, current documentation and runbooks, and an agreed number of days of transition support. These problems surface only after an engagement ends, and renegotiating then is one-sided, because you have nothing left to withhold.

Watch for the payment-contingent assignment trap too. Many contracts transfer IP only on full payment, which hands the agency your product as leverage in any billing dispute; milestone-based assignment is more balanced and usually accepted without argument.

The playbook

1. 1
   Read only the IP clause first.

   Find the ownership section before you look at the price. It should say the agency assigns all intellectual property in the deliverables to you, in writing, and separately list anything they are keeping. If that list is vague, ask for specifics.

2. 2
   Ask for the third-party inventory.

   Request a list of open-source licences and paid third-party services in the build, plus their policy on AI-generated code. Two-thirds of codebases now carry licence conflicts, and this is exactly what investor due diligence looks for.

3. 3
   Move the accounts into your name this week.

   Your own GitHub or GitLab organisation, your own cloud account with your card on it, your own domain — then invite the agency in. An afternoon now saves a month later.

4. 4
   Name the humans, and price the exit.

   Put the people you were actually sold into the contract as key personnel, with substitutions needing your approval. In the same breath, define handover as a written scope — source code, repository access, credentials, environments, design files, documentation, runbook — at an agreed price or day count.

5. 5
   Run the walk-away test before you sign.

   If this ended badly next Tuesday, could another team pick it up? If the honest answer is no, you have found your lock-in. Fix it in the contract, or escrow the source code as a fallback, before you commit.

The strongest signal is not in the paperwork — it is how the agency reacts when you ask. The good ones have been asked before, and hand over the assignment clause without being chased. The ones who get defensive are telling you something useful for free. You are not buying code; you are buying the ability to keep building without the people who wrote it.