Most advice about hiring a development agency assumes the relationship is starting. This post is for the messier, more common moment: you’re already in one, and something isn’t working.
Maybe your agency has gone quiet. Maybe deadlines keep slipping. Maybe you’re realising, a year in, that you never actually got the code ownership you thought you’d paid for. None of that makes you unusual, it makes you exactly who this guide is for.
We’ve written this from the position of a UK-based development team that gets called in on both sides of this: clients switching away from someone else, and clients coming to us after building something themselves. The honest starting point is this, most friction is fixable, switching is disruptive even when it’s the right call, and the order you do things in matters more than almost anything else here.
Common problems that lead people to consider switching
They're offshore, and you need UK-based contractors for a grant-funded project
If your project has grant funding attached, an offshore build can put that funding at risk before you’ve even noticed a problem with delivery. Innovate UK competitions generally require subcontractors to be based in the UK for the duration of the project, with UK-based work, and won’t accept lower cost alone as justification for going overseas. The Channel Islands and Isle of Man don’t count as “UK” for this purpose either, since they’re Crown Dependencies. EUREKA Eurostars funding has its own domestic rules: work and costs must sit in the UK, labour has to be PAYE, and subcontracting is capped at 20% of the UK partner’s eligible costs. Rules vary by competition, so always check the specific terms rather than assuming, but if you’re grant-funded and your build isn’t, that’s worth raising immediately, not at renewal.
If you’re in healthcare or public sector, there’s a second layer: NHS guidance on offshoring and public cloud has required cloud services and data to be repatriated to UK regions since 2017, with hosting outside the UK needing SIRO and senior management approval. Health data counts as special category data under UK GDPR, and the NHS Data Security and Protection Toolkit is the mandatory annual self-assessment for anyone handling NHS patient data. One nuance worth knowing: hosting data in a UK region gives you residency, not sovereignty, data held with a US-headquartered cloud provider can still fall within reach of the US CLOUD Act even from a UK data centre.
"Japeto Labs holds NHS DSPT and Cyber Essentials Plus and works to an information security policy that governs vendor selection, hosting, and data access. Client hosting for Japeto's own infrastructure runs from London data centres, so data stays in the UK by default. We have a choice of AI models in different regions, and we select suitable models for clients based on their data residency needs."
They're great, but you're having trouble with timelines
Slipping timelines aren’t automatically a red flag. Software is uncertain, iterative work, and “fast, cheap, good, pick two” is a cliché because it’s usually true. If a project is running late, the useful next step is a re-baselined plan with real milestones, and an honest conversation about whether the cause is scope creep, unclear requirements, or genuine capacity problems on the agency’s side. That’s a very different conversation from “the team disappeared.”
Communication has gone downhill
Response times during the sales process are usually the best they’ll ever be. If replies are already slow before you’ve signed anything, that’s a preview, not an outlier. Worth agreeing explicitly, in writing: a fixed comms cadence (a weekly demo of working software, a written status update), a single named point of contact, and a shared channel.
Signs your development agency is about to fail
Some warning signs worth watching for as a pattern, not a single incident:
- The senior person who sold you the work quietly disappears from calls
- Staff on your account keep changing without explanation
- Deadlines keep slipping, three missed in a row is a reasonable line to treat seriously
- You get verbal status updates instead of demos or working software
- Excuses start replacing artefacts you can actually look at
- Payment terms shift: requests for money upfront, changed bank details, unusual urgency
If you want to check the financial health of a UK agency directly, a few free or cheap sources help:
- Companies House, look for overdue accounts or confirmation statements, a sudden switch to smaller/abbreviated filings, or director resignations. Late filings are a real signal, though CCJs won’t show up here directly.
- County Court Judgments (CCJs), checked via the Register of Judgments, Orders and Fines, or services like Creditsafe/Experian/Capitalise. A CCJ paid within a month doesn’t appear publicly; otherwise it stays on the register for six years. Multiple or recent CCJs point to cash-flow trouble.
- Credit reference agencies combine both of the above with trade-payment history into a single score.
This is protective due diligence, not paranoia, and it’s just as relevant when vetting a new agency as when worrying about your current one.
Questions to ask yourself right now
- Has the senior person I originally dealt with been on a call in the last month
- Has the team on my project changed without an explanation?
- Have I seen a working demo recently, or only verbal updates?
- Have I missed three or more deadlines in a row?
- Has anything changed about how or when I’m asked to pay?
- Have I checked Companies House for this agency in the last six months?
What to do when a development agency goes silent
Agencies rarely send a formal “we quit” email. Silence and drift are the usual pattern, not a clean announcement. If you’re in that situation, here’s a reasonable escalation ladder for England & Wales:
- Document everything. Emails, call notes, meeting minutes, agreed scope, timelines, and any changes to them, courts favour a paper trail.
- Secure what you already have access to. Copy the code, data, assets, and credentials you can already reach, before you escalate further (see the handover checklist below)
- Send a formal written chase. Reference the contract, list what’s outstanding, and set a clear deadline.
- Check the contract’s termination provisions. Notice periods, cure periods, and whether termination is for cause or for convenience all matter.
- Letter Before Action (LBA). A formal pre-action demand setting out the breach, the loss, what you want, and a deadline, typically around 14 days for something straightforward, 28–30 days for a more complex breach-of-contract dispute the other side needs to investigate. State a willingness to mediate; courts can penalise a party who refuses ADR unreasonably.
- Mediation. Usually cheaper and faster than court, the Small Claims Mediation Service is free for claims on the small claims track.
- Court, if it comes to that. The small claims track covers claims up to £10,000 in England & Wales via the government’s money claims service; the County Court generally handles up to £100,000. Any settlement should be recorded in a Deed of Settlement. The limitation period for breach of contract is generally six years (twelve for a deed).
Questions to put in your formal written chase
- What specifically is outstanding, and by when was it due?
- What does the contract say about notice periods and cure periods?
- Is this a termination for cause or for convenience, and does that change what I’m owed?
- What access do I currently have, and what do I still need to secure?
- What’s a fair, clearly stated deadline for a response before I escalate further?
Offshore development agency bait and switch signs
To be clear upfront: plenty of excellent offshore teams exist, and this isn’t an argument against offshore development. But there’s a specific, well-documented failure pattern worth naming, senior engineers close the deal, then junior contractors deliver the actual project, sometimes with the team quietly subcontracted or rotated between clients.
Signs worth watching for:
- Only business-development contacts are available before you sign; vague answers about who does the day-to-day work
- No named project manager or technical lead
- A “senior” developer quoted well below the going market rate
- Once delivery starts, code quality feels inconsistent and decisions lack long-term thinking
- A team that agrees with everything and never pushes back, experienced engineers challenge assumptions and flag risk
Experienced buyers routinely ask for CVs of every assigned developer before signing, not after, and insist on meeting the actual delivery team. Asking a past client directly, “was the team that showed up the team that was sold to you?” tends to surface the truth quickly.
Questions to ask before you sign
- Can I see CVs and seniority levels for the specific people who’ll work on this, not a general team profile?
- Who is my named project manager or technical lead, and can I meet them now?
- Can I speak to a past client and ask them directly whether the team that delivered matched the team that was pitched?
- What happens, contractually, if a named person leaves or is swapped out mid-project?
How to tell if your offshore team changed without telling you
A few practical detection methods, roughly in order of reliability:
- Git commit history. Git is the system almost every developer uses to track changes to code. Every commit records an author and a timezone offset, so a sudden shift in author names, email domains, or working hours is a signal worth asking about. It’s not proof on its own, offsets can be manually set, but it’s a useful starting point.
- Code-style shifts. Abrupt changes in formatting, naming conventions, or commit-message style.
- Video-call attendance. Are the people you were introduced to actually on calls, and able to speak fluently about the code?
- Named developer CVs and a contractual right to approve team changes, key-personnel clauses that name individuals and require notice of substitutions.
- A quick LinkedIn check, do the named developers exist, and does their role and location match what you were told?
Offshore vs onshore development agency risk
| Factor | Consideration |
|---|---|
| Cost | Offshore rates are typically lower, but communication overhead and rework can erode a meaningful chunk of the saving |
| Time zones | Offshore can mean 12–24+ hour feedback loops; onshore allows same-hours collaboration |
| IP enforcement | Code created abroad can be harder to protect, and cross-border enforcement is harder in some jurisdictions |
| Data protection | Keeping data onshore simplifies UK GDPR compliance; international transfers add legal obligations |
| Grant eligibility | Some UK grants require UK-based work |
| Governance | Offshore models need more documentation and disciplined process to stay transparent |
It isn’t “offshore bad, onshore good”, it’s about fit and governance. Hybrid models, offshore delivery with onshore oversight, are common and can work well. The real question is whether your project has constraints, grant funding, NHS data, heavy real-time collaboration, that push you toward one model over the other.
Switching software development agencies mid-project
The pre-switch checklist
One piece of advice that sounds counter-intuitive but matters: line up your new agency before ending the relationship with the old one. A new agency will help to scope the handover and act as a technical translator during the transition. Plus, you also avoid the dangerous gap where nobody is actually holding the code.
1. Find your contracts and understand your exit clauses
This is where IP ownership becomes the biggest trap in the entire process, so it’s worth slowing down here even though it’s the least fun part of switching agencies.
The short version: in UK law, whoever writes the code owns it by default, not whoever pays for it. Paying your invoices doesn’t automatically make the code yours. For it to legally become yours, your contract needs a specific clause, called an “assignment,” that says so in writing. If your contract doesn’t have one, or you’re not sure, that’s the single most important thing to sort out before you go anywhere near switching agencies.
Here’s why, in a bit more detail. Software counts as a “literary work” under the Copyright, Designs and Patents Act 1988, and copyright in it belongs automatically to whoever wrote it, your developer or agency, not to you, even though you commissioned and paid for it. The only way that ownership moves to you is through a written, signed assignment clause in your contract. It’s worth knowing the difference between two terms that get used loosely:
- Assignment: ownership transfers to you outright. This is what you want.
- Licence: you’re given permission to use the software, but the agency still legally owns it.
A contract that only grants a licence, even a generous one, means you never actually own the code, you’re renting the right to use it.
There’s a second trap worth knowing about even if your contract does have an assignment clause: some contracts only transfer ownership once full payment has been made, sometimes worded as vesting “immediately following the later of” acceptance or full payment. That sounds reasonable, but it means a payment dispute can leave you without a legal claim to code you’ve mostly paid for.
This isn’t a hypothetical risk, in Transparently Ltd v Growth Capital Ventures Ltd [2022] EWHC 144 (TCC), a client terminated a software development agreement and asked for the source code, but the court declined to order its release because the contract’s ownership condition, which included an equity payment, had never actually been satisfied. The client was left without the code they’d paid for.
If you don’t have a written contract at all, ownership is genuinely murky: the developer likely still owns the copyright by default, and you may only have an informal (“implied”) licence to use what you paid for. Getting a proper written assignment signed, even retroactively, should be a priority before you do anything else.
Also check while you’re in the contract: notice periods and whether termination is for cause or convenience, any restrictive covenants (e.g. non-solicitation of the agency’s own staff), and whether source code escrow is in place (more on that below).
Questions to find the answer to in your own contract
- Does it say IP is assigned to me, or merely licensed?
- Is the assignment written and signed, or only implied?
- Does IP vest immediately, or only on full payment (and if so, what counts as “full”)?
- What are the notice periods, and is termination for cause or for convenience?
- Are there restrictive covenants I need to be aware of?
- Is there a source code escrow arrangement in place?
If you can’t answer these confidently from the document in front of you, that’s worth a short call with a solicitor before you do anything else.
2. List outstanding work in progress
Get a written status update and a realistic timeline for everything currently in flight, from the existing team, before you give notice.
3. Build a single inventory document
List every place your project actually lives: the codebase location (GitHub, GitLab, Bitbucket, or local-only), hosting and cloud accounts, and every third-party service and account, domains, DNS, email, SSL certificates, payment providers, analytics, app-store accounts, API keys, SaaS subscriptions. This inventory becomes the backbone of the whole handover.
How to fire a software development agency without losing your code
The order matters more than almost anything else in this process. Get the code, get it in writing, then get out.
- Secure access and backups first, while you still have access, clone repos, export databases, download assets, copy environment variables, take a full backup.
- Get the IP assignment confirmed in writing, and pay any genuinely outstanding sums to remove the agency’s leverage and avoid a dispute.
- Then give notice, following the contract’s process.
Doing this in a different order, giving notice first, then trying to negotiate access, is how people end up in the Transparently situation above.
How to take over a codebase from a fired development agency
From the other side of the table: inheriting someone else’s project is normal, well-understood work, not an emergency and not a drama. A good agency won’t reach for a big-bang rewrite unless the numbers genuinely demand one.
What a good discovery phase looks like
Best practice is a paid assessment first, typically one to two weeks of read access while the current setup keeps running. This is close to what we’d call a tech roadmap workshop: a scoped, paid discovery phase before any commitment to build. What should come out of it: a documented architecture, a clear split between quick wins and structural risks, a written plan before any significant code changes, and a phased approach so you’re not asked to sign off months of unseen work.
One useful red flag to watch for on the receiving end: if a new agency hands you a firm, final quote before finishing that audit, treat it as a reason for caution rather than comfort. Nobody can responsibly price unknown code sight unseen.
Questions to ask a new agency during discovery
- Will you give me a written architecture summary and a list of quick wins vs. structural risks before recommending a plan?
- Will you commit to a firm quote only after the audit is complete?
- How will you handle undocumented decisions in the code, do you talk to the previous team, or reverse-engineer from scratch?
- What’s realistic ramp-up time before you’re moving at full speed?
The access checklist, get ownership, not just access
Aim for full admin/owner-level access, not collaborator access, for:
- The source code repository (GitHub, GitLab, Bitbucket), all branches
- Hosting and cloud infrastructure (AWS, GCP, Azure, DigitalOcean, Vercel, Netlify, Heroku)
- Databases
- Environment variables and secrets
- CI/CD pipelines
- Build and deployment instructions
If it’s a solo engineer rather than an agency, the code may only exist locally, insist it’s zipped, organised, and delivered along with the database, environment variables, and build instructions.
A proper handover pack
A good handover includes version-control repos and the branching strategy, an explanation of repo structure and purpose, architecture documentation, notes on known tech debt and “why we did it this way” decisions, credentials plus admin and demo accounts, deployment docs, and at least one live knowledge-transfer session walking through the codebase. Name one accountable person on each side.
"Once access is actually in hand, the first thing checked is access itself, not code quality. No stored credentials left in the codebase, and confirmation that any previous developers have had their access properly revoked. This makes sure that Japeto Labs knows and controls who has access to the project and its data. From there, a full audit follows: checking every third-party library the code depends on for known security issues, common on projects that have been running a while. As well as running the code through a quality scanner (SonarQube) to flag performance, security, or maintainability problems before anything else gets touched. Only then does the new team set up test environments and tooling to start working with the project properly."
Hosting and domains: usually the straightforward part
Hosting transfers are best done account-to-account, facilitated between the outgoing and incoming agency. The golden rule: the destination account should be owned by the client, not either agency.
| Platform | How the transfer works |
|---|---|
| AWS | No single "hand over the account" button, either update the root user's email, password, and payment method, or migrate resources between AWS Organizations |
| Azure | Formal billing-ownership transfer of the subscription; moving to a different Microsoft Entra tenant wipes existing RBAC role assignments, which have to be re-created |
| Google Cloud | Project migration re-parents the project with zero downtime; org-to-org moves need matching export/import policies on both sides |
| DigitalOcean | Droplets can't be transferred directly between accounts, only snapshots, and they're moved rather than copied; other resources need re-creating |
| Heroku | First-class transfer via heroku apps:transfer; the original owner becomes a collaborator |
| Vercel | Project → Settings → Transfer Project; zero downtime, domains move automatically, but integrations and secure compute need re-adding |
| Netlify | Project → General → Transfer project, to any team you're an Owner or Developer on |
WordPress-specific hosts (WP Engine, Kinsta, SiteGround, 20i, Krystal) generally offer built-in migration tools, and several, Kinsta in particular, explicitly market free migrations for exactly this situation.
Domain transfers work differently depending on the TLD. .uk domains transfer via an IPS tag change rather than an auth code, the current registrar has to actively cooperate, and if they stall, Nominet’s member portal lets you change it directly (for a small fee). .com/.net/.org and other gTLDs need an EPP/auth code and are subject to ICANN’s 60-day transfer locks; .uk domains aren’t bound by that rule.
How Japeto approaches this in practice
For websites – typically we move clients over to our own hosting. Handover steps:
- Set up hosting accounts on our system for the client
- Copy files and database hosting from the old host to the new one
- Update the domain to point at the new hosting
This ensures a transfer with no downtime.
For more complex sites with frequently updated data (e.g. stores), we typically manage the migration during low traffic periods (like early hours of the morning) and set up temporary redirects from the old hosting to the new to keep downtime to a minimum and ensure there is no data loss.
For systems like apps, this is usually bespoke and we work with AWS. Often clients come to us with prototypes or early-stage apps which have been hosted on a single server. We assess the needs of each client (scaling, performance and fault-tolerance) and move it onto robust architecture.
"Our preferred pattern is credential handover because we fully manage client hosting in most cases, so we transfer hosting over to our infrastructure."
Worth being upfront about the nuance here: this a different model from the “own every account yourself” principle in the next section. However this is becasue Japeto Labs is managing the hosting day-to-day rather than the client running their own infrastructure with Japeto as a collaborator. If account ownership matters more to you than having hosting fully managed, that’s worth raising directly before work starts.
Staying independent, for next time
This is arguably the most useful section in this whole post, and the one that costs an agency the least to say and the most to actually mean.
- Data protection. Your old agency was almost certainly a data processor under UK GDPR; the new one needs a Data Processing Agreement under Article 28 in place before touching personal data , and if your organisation itself processes data under a controller’s authorisation, the controller needs to be notified of the change.
- Licences and paid components. Themes, plugins, fonts, APIs, and SaaS subscriptions need confirming as licensed to you, not the agency.
- App-store account ownership, transferred properly rather than left under the old agency’s developer account.
- Who fixes production issues during the transition window , agree this explicitly rather than assuming; a formal support retainer exists precisely to cover this kind of gap.
- Knowledge-transfer sessions with the outgoing team, booked while goodwill still exists.
- Pay the final invoice. Clearing genuinely-owed sums removes the code-withholding leverage entirely and avoids a dispute that outlasts the actual project.
- Professional indemnity insurance, particularly relevant if you’re working with the NHS or public sector.
- Source code escrow, for genuinely business-critical software , a neutral third party (NCC Group / Escode is the best-known UK provider) holds the source code, released on pre-agreed trigger events like supplier insolvency. Worth knowing: escrow gives you the right to the code, not instant continuity.
- Revoke old access once you’ve genuinely confirmed the new team has everything it needs.
Worth being straight about where Japeto stands on this today: source code escrow isn’t something currently offered. However Japeto Labs is open to finding a provider for this, though nobody has required this to date.
If it’s something you’d want as part of an engagement, it’s worth raising directly rather than assuming it’s already covered.
A few things worth checking that don't fit neatly anywhere else
- Data protection. Your old agency was almost certainly a data processor under UK GDPR; the new one needs a Data Processing Agreement under Article 28 in place before touching personal data, and if your organisation itself processes data under a controller’s authorisation, the controller needs to be notified of the change.
- Licences and paid components. Themes, plugins, fonts, APIs, and SaaS subscriptions need confirming as licensed to you, not the agency.
- App-store account ownership, transferred properly rather than left under the old agency’s developer account.
- Who fixes production issues during the transition window, agree this explicitly rather than assuming.
- Knowledge-transfer sessions with the outgoing team, booked while goodwill still exists.
- Pay the final invoice. Clearing genuinely-owed sums removes the code-withholding leverage entirely and avoids a dispute that outlasts the actual project.
- Professional indemnity insurance, particularly relevant if you’re working with the NHS or public sector.
- Source code escrow, for genuinely business-critical software, a neutral third party (NCC Group / Escode is the best-known UK provider) holds the source code, released on pre-agreed trigger events like supplier insolvency. Worth knowing: escrow gives you the right to the code, not instant continuity.
- Revoke old access once you’ve genuinely confirmed the new team has everything it needs.
None of this is a reason to be defensive with an agency that’s actually doing right by you, most relationships don’t end up here. But if you’re already mid-problem, the sequencing above is the difference between a clean switch and a genuinely painful one.
If you’d rather talk it through than read the rest of the internet’s advice on this, we’re happy to be that conversation, including as the calm second opinion before you’ve decided anything.
