Freelancer Not Delivering? When to Hire an Agency Instead

If your freelancer has missed two milestones in a row, cannot show you running software and has gone vague when you ask for status, start the exit now and hire an agency or a second freelancer to take over. If it has been one bad month from someone who has delivered before, give them a written deadline and a smaller scope first. Switching costs real money, so do it when the evidence is there and not when you are only annoyed.

Most founders wait too long. The freelancer is friendly, the excuses are plausible, and every week of delay feels like a reason to wait one more week. Three months later you have spent $20,000 and own something nobody can demo.

This article covers the signs, the cases where an agency is the wrong move, how to find out what you actually have, how to get your code and accounts out, what a handover costs and how to run the transition. For the wider choice between models, read in-house vs agency vs freelance. If your current team is an agency and not a person, how to switch dev agencies mid-project is the closer match.

One late task means nothing. A pattern means a lot. These are the signs I would treat as serious, roughly in order of how much they worry me.

• Missed milestones, twice. The first miss is life. The second, with a new date attached, is a habit. If the new date also slips, you have your answer.
• No repository access. Your code lives on their laptop or in their GitHub account, and you have never seen it. This one is a red flag even when everything else looks fine, because it means you cannot leave quickly.
• No demos. You get screenshots, a screen recording from three weeks ago or a promise that it will all come together at the end. Working software shown on a phone is the only status report that counts.
• Vague status. "Making good progress on the backend." "Just polishing a few things." Ask what was finished since last Friday. A person who is shipping can name three things. A person who is stuck cannot.
• Scope that keeps growing. Every update includes a new reason the work is bigger than quoted: an API changed, a library broke, the design needs a rethink. Some of that is real. All of it, every week, is not.
• Slow replies and shrinking hours. A freelancer who answered in an hour in month one and answers in three days in month four has taken on other clients. You are no longer the priority.
• Payment pressure without output. Requests to pay ahead, or to convert from milestones to hourly, right when delivery slows down.

Count them. One or two, with a freelancer who has a track record with you, is a conversation. Four or more is an exit plan.

The test I use

Ask for a live demo on your own phone within 48 hours, of whatever is built so far. Not a polished one. If it happens, even with bugs, you are probably dealing with a slow project. If it does not happen, or comes with a reason it cannot, you are probably dealing with a stalled one.

I run an agency, and there are plenty of cases where I would tell you to stay with the freelancer or hire a different one. Be honest with yourself about these before you spend anything.

The scope is small

If what remains is a few screens, a bug list or a single integration, an agency is overkill. A good freelancer fixes that for $3,000 to $15,000 and an agency will have minimums that make it pointless. Find another freelancer, hand them the repo and a short list.

The freelancer is good and had a bad month

People get sick, lose a parent, take on a client that blows up. If this person delivered the first two milestones on time and showed you working builds, one missed deadline is not a pattern. Write down what is left, agree on a date and ask for a demo at the halfway point. You keep the context in their head, which is worth more than most founders realize.

You do not have the budget

Agencies cost more per hour than freelancers, usually by a factor of one and a half to three. A US agency commonly bills $125 to $250 an hour, against $50 to $150 for a freelancer depending on country and seniority. If you have $10,000 left, an agency cannot finish a project that already burned $40,000. You are better off with a second freelancer and a tight scope.

Your requirements are still unclear

This one matters most and gets missed. Many "freelancer not delivering" stories come down to "nobody wrote down what to build." If you cannot describe the first release in a page, with the screens, the user types and the one thing it has to do, a new team will hit the same wall. Fix that first. Sometimes it takes a week of work with a product person and a few sketches, and it costs less than any rebuild.

If none of these four apply, and the signs in the section above do, then yes, it is time to look at a team. The rest of this article assumes that.

Do not fire anyone yet. First find out what exists. The audit takes a few days and changes your choices. You might find a decent codebase that needs finishing, or an unfinished mess that is cheaper to restart.

Get repository access

Ask for admin access to the code repository on GitHub, GitLab or Bitbucket, in an organization you own. If the code is in their personal account, ask them to transfer it or add you as owner. A reasonable freelancer says yes in a day. If you get delays or reasons, treat that as information, and move to the exit steps in the next section in parallel.

See a running build

You need to install and use the app, not look at code. For mobile, that means a TestFlight build on iOS and an internal test track or APK on Android. For web, a staging URL. Click through every screen the freelancer says is finished. Write down what works, what crashes and what is a placeholder. A spreadsheet with three columns is enough: done, partly done, not started.

Have a second engineer review the code

Pay an independent senior engineer, ideally someone from the team you might hire, to read the repository for a few hours. Budget $1,500 to $5,000 for a review of a small app, up to $10,000 for a larger codebase with a backend and several integrations. They should answer five things:

1. Does it build and run from a clean checkout, using the README alone?
2. Is the structure something another engineer can work in, or is it one 4,000-line file?
3. Are there tests, even a few?
4. Where do secrets, API keys and third-party accounts live?
5. What would it cost to finish versus rebuild?

The last one is the answer you are paying for. If you are unsure how to judge the work yourself, how to evaluate developer work covers what to look at and what to ignore. Our rule of thumb: if finishing costs more than about 60 percent of a rebuild, rebuild. Below that, finish.

Do this before the hard conversation. Founders who tell the freelancer they are leaving, and then ask for access, sometimes end up negotiating for their own product.

The access list

• Source code. The repository, all branches, owned by your organization.
• Apple Developer and Google Play accounts. These should be in your name, with the freelancer as a team member. If the app was published under their account, the transfer takes weeks and needs both sides, so start immediately.
• Cloud hosting. AWS, Google Cloud, Vercel, Supabase, Firebase or wherever it runs. You want to be the root or owner.
• Domain and DNS. Registrar login, in your name.
• Third-party services. Stripe, Twilio, SendGrid, analytics, push notifications, crash reporting, map keys. Each one has an owner. Find out whose email it is.
• Design files. Figma, with edit access.
• Documentation. Whatever exists: environment variables, deploy steps, API notes. Often it is nothing.

Make a copy of all of it. A repository clone on your own machine or a private repo you control takes ten minutes and protects you if the relationship turns bad. Change shared passwords and rotate API keys once you have what you need.

Check your contract

Read what you signed. Many freelance agreements say ownership transfers on final payment, not on delivery. That is common and fair, but it means a dispute over the last invoice can hold your code. If there is a gap, offer to pay what is owed for work you can verify, in exchange for a written assignment of the code. A lawyer for an hour, at $300 to $600, is cheaper than a stalled launch.

Have the conversation

Keep it short and factual. You are ending the engagement, here is the list of what you need, and by what date. Do not argue about blame. If they cooperate, thank them. A clean handover from a freelancer who feels respected is faster and cheaper than one wrung out of an angry one.

A handover is the cost of a new team understanding what exists, plus fixing whatever is broken enough to block progress. These are market ranges for the US and Western Europe in 2026. They are not quotes, and anyone who gives you a fixed figure before reading the code is guessing.

• Code review and audit: $1,500 to $10,000, one to two weeks. Driven by codebase size and how many systems it touches.
• Environment setup and access cleanup: $1,000 to $5,000. Higher if accounts are in the freelancer's name or nothing is documented.
• Stabilization: $5,000 to $30,000. Fixing the crashes, the broken builds and the security holes that stop anyone building on top of it.
• Documentation and knowledge transfer: $1,000 to $6,000, mostly the new team writing down what they learned, plus a few calls with the old developer if they will do them.

Add those up and a typical takeover of a small to mid-size app costs $8,000 to $40,000 before any new features. A rebuild of the same app often lands between $40,000 and $150,000 or more, depending on features, platforms and integrations. Those are the two numbers to hold next to each other when the audit comes back.

What pushes the number up

• No tests and no documentation.
• An unusual stack that few engineers know, or a framework version that is several years old.
• Business logic buried in the client app instead of a backend.
• Accounts and keys owned by someone who has stopped replying.
• A freelancer who is hostile or gone. Their cooperation saves days of guessing.

What pulls it down

• A common stack such as React Native, Flutter, Next.js or Swift.
• A README that works.
• Commit history that shows steady, readable work.
• A freelancer who agrees to two or three handover calls.

The money already spent is gone either way. Do not let it decide the next step. Ask only what it costs from today to get to a launched product, and which route gets there faster with less risk.

The goal is to keep what works, stop the bleeding and ship something visible in weeks, not quarters. This is the order I would follow.

Week one: freeze and secure

Stop new feature work. Collect the access list, clone everything, run the audit and write down the decision: finish or rebuild. Settle the final invoice terms with the freelancer in writing, tied to the handover items above.

Weeks two to three: get it running

The new team builds the app from scratch on their machines, sets up a staging environment and gets a build onto a phone. This is the point where you find out whether the audit was right. Expect surprises, and budget a buffer of 20 percent for them.

Weeks four to eight: ship something small

Pick the smallest piece of the remaining scope that a real user would notice, and ship it. A fixed bug list or one finished flow, such as onboarding or checkout. This restores your trust in the process and gives the new team a clean baseline. Do not start with the biggest unfinished feature.

Set the cadence

Whatever caused the first failure should not exist in the second arrangement. That means a weekly demo on a real device, a repository you can read, a written backlog in a tool like Linear or Jira, and a short written status on the same day every week. If a team resists any of those four, that tells you something.

Keep the old developer in the loop if you can

If the relationship is not poisoned, pay for three or four hours of their time at an hourly rate. A walkthrough of the architecture and the odd corners of the code saves the new team days. Offer it, and accept a no.

You have been burned once, so you are allowed to be thorough. These are the questions that separate teams that finish from teams that talk.

• Who will actually write the code? Names and seniority, not "our team". Ask to talk to the lead engineer before you sign.
• What do you do in the first two weeks of a takeover? The right answer includes an audit, a build from scratch and a written plan. A fast quote with no audit is a red flag.
• Can I see a running build every week? Yes, on a real device, without being asked.
• Who owns the code and the accounts? You. From day one, not on final payment.
• How do you handle a codebase you did not write? Ask for a past example of a takeover, how it went and what it cost. Ask for a reference you can call.
• What happens if we part ways? They should have a clear answer on handover, documentation and notice period. A team that has thought about this is a team that expects to be held to it.
• What will you tell me is a bad idea? You want someone who says no sometimes.
• How is the work priced? Fixed scope with milestones, or time and materials with a cap. Avoid open-ended hourly with no ceiling after what you just went through.

A short paid discovery or audit, one to two weeks, is a good way to test any team before committing the full budget. You see how they communicate, what they find and whether the plan is specific. If they cannot produce a plan with dates and a number, move on.

Compare at least two. The cheapest quote after an audit is rarely the right one, and the most expensive is not always better. Pick the team whose questions about your product were sharpest.

Taking over a stalled app is part of what we do at Kanopy. We start with an audit of the repository and a running build, tell you plainly whether to finish or rebuild, and show you working software on your phone every week. You own the code and the accounts from the first day. If your project is small enough that a freelancer is the better answer, we will say so on the first call.

If your freelancer has stopped delivering and you want a second opinion on what you have, book a free strategy call.