# When to Fire Your Dev Agency and Bring Development In-House
Switching from agency to in-house development is a transition that founders often delay too long. The signs that the agency relationship is broken accumulate over months. The conversation feels uncomfortable. There is sunk cost bias - you have already invested so much, maybe it will get better. So you wait.
By the time most founders call me about their agency situation, the relationship has been dysfunctional for 6-12 months and the technical debt from that period is substantial.
A founder I worked with had been with her agency for 14 months. The first three months were reasonable. Then the original lead developer assigned to her project left the agency. Then another one. By month six, she was on her third account team and the new people did not understand the codebase as well as she did at this point. Features were taking twice as long as quoted. Bugs introduced in one sprint were not caught until the next. The agency's project manager kept assuring her things would stabilize.
By the time she called me, she had paid $340,000 to the agency and had a product she was embarrassed to show investors. We needed two months of in-house work to stabilize the codebase before she could bring on a proper engineering team.
The signs were there at month four. She should have made the transition at month six.
Signs the Agency Relationship Is Broken
The clearest signs are operational. They do not require technical expertise to recognize.
High developer turnover on your account. If you are on your third or fourth project lead in a year, the agency has a staffing problem that is directly affecting your product. Institutional knowledge about your codebase and business logic walks out the door with every developer transition. Each new person starts with partial understanding and makes decisions based on incomplete context.
Budget overruns on every project. Occasional scope creep is normal. Consistent overruns - where every sprint or project phase costs more than quoted - indicate either that the agency is underquoting to win business (and charging the real cost later) or that they do not have enough control over their own process to predict costs accurately. Either way, you cannot trust their estimates.
Long cycles between bug report and fix. In a healthy development relationship, bugs are triaged and addressed within a sprint cycle. When significant bugs sit for 2-4+ weeks, the agency has either deprioritized your account or does not have the team capacity to handle their workload. You are not their most important client - that is fine, but it affects your outcomes.
You cannot get a clear technical explanation of decisions. When you ask why something was built a certain way and receive vague answers or are told "it's how we always do it," the agency cannot explain their own decisions. That is either because the developer who made the decision has left, or because the decision was made without enough thought to be explainable. Both are concerning.
You are doing more project management than the agency is. An agency engagement should feel like you provide direction and receive progress. When you find yourself creating detailed tickets, following up on stalled work, and coordinating between the agency's own team members, you are doing their job and paying them for it.
The Technical Signs (For When You Have a Technical Advisor)
No tests or test coverage far below what was agreed. An agency that agreed to maintain 70% test coverage and delivers at 20% is not meeting their contractual obligations and is delivering a product that is riskier to operate and extend.
Inconsistent code quality that reveals frequent developer changes. When different parts of the codebase look like they were written by different people who have never discussed conventions - different naming styles, different error handling patterns, different approaches to the same type of problem - it indicates high turnover on your account and no senior oversight to maintain consistency.
Critical bugs in untouched areas of the codebase. When fixes in one area introduce bugs in a completely different area that no one touched, the codebase is too tightly coupled and the developers do not have enough understanding of it to make changes safely.
Infrastructure and configuration not documented. When you cannot get a clear picture of how your system is deployed, what environment variables it uses, what external services it depends on - and the agency cannot provide this documentation - you do not actually own your own system.
How to Execute the Transition
The transition from agency to in-house requires planning to avoid gaps in development capacity and to ensure the in-house team is not starting from zero.
Step 1: Get everything you need from the agency while the relationship is still active. Source code with full history, database schemas and current data exports, environment variable documentation, deployment credentials, and a written system architecture overview. Do not wait until after termination to request this - agencies are much more cooperative before you have told them you are leaving.
Step 2: Technical audit before you hire. Before building an in-house team, bring in a technical advisor to assess what the agency has built. You need to understand what you are working with: how much technical debt exists, what the highest-priority cleanup items are, and whether there are any critical security or reliability issues that need immediate attention.
Step 3: Hire in the right order. Your first in-house hire should be a senior engineer or engineering lead who can assess the codebase, set standards, and then build the team. Do not hire junior engineers first and then bring in the senior later - the seniors need to establish the foundation.
Step 4: Overlap period. Do not cut the agency off on the day you hire your first in-house developer. Plan for a 4-8 week overlap period where both are working. During this period, the in-house engineer learns the codebase from the agency through explicit knowledge transfer sessions, and the agency continues to maintain the product while the in-house team gets up to speed. This overlap is worth the cost.
Step 5: Establish the new systems before the old ones end. Before the agency engagement terminates, your in-house team should have: version control set up, a deployment pipeline they own and understand, monitoring configured, and at least one full deployment cycle completed. You want to end the agency relationship from a position of independence, not panic.
What the Timeline Actually Looks Like
Announce the transition decision: month 1. Request documentation and knowledge transfer: month 1-2. Hire first in-house engineer: month 1-2 (recruiting takes time; start immediately). Overlap period with agency: month 2-3. Agency engagement ends: month 3-4. First in-house engineer fully ramped: month 4-5. Begin in-house team expansion: month 4+.
This timeline feels slow when you are frustrated with an agency, but rushing it creates new problems. The goal is not to end the agency relationship as fast as possible - it is to transition to in-house without losing continuity.
The founders who execute this transition well are the ones who plan it like a project, not a breakup.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr