When should an SMB replace a development agency?

Replacing a development agency with two in-house AI-augmented engineers works when the business has a stable six months of product demand, owns its operating assets, and can buy specialist help without outsourcing product judgment. It fails when a founder treats two salaries plus AI subscriptions as a cheap substitute for every role hidden inside an agency.

I have reduced a much larger engineering operation to two engineers using AI while keeping delivery and uptime. The reduction worked because we redesigned the work, access, review, and operations around a small accountable team. Headcount was the last change, not the first.

The decision should produce a written operating case. It needs a demand map, a clean ownership transfer, an honest transition budget, named incident duties, and a plan for skills the two hires will not carry. If one of those stays vague, keep the agency while you fix it.

Six months of steady demand justifies the switch

Replace the agency when most of the next six months consists of continuous work on one product, not a temporary build followed by silence. Two internal engineers earn their advantage through accumulated context. They remember why a billing exception exists, which customer workflow must not change, and how a harmless schema edit can affect support. An agency can retain that context, but every change request, account handoff, and staffing rotation makes retention less reliable.

Turn the roadmap into delivery demand before comparing costs. For every expected piece of work, record the business deadline, systems touched, uncertainty, required specialist, and operational consequence. Include maintenance that founders usually omit: dependency updates, support investigations, security remediation, deployment work, data corrections, monitoring, and recovery tests. A roadmap that contains only features understates the job.

Use three demand categories. Product work changes what customers can do. Operational work keeps the current service trustworthy. Discovery work reduces uncertainty before anyone commits to a build. Two experienced engineers can handle a substantial flow when product work is reasonably sequenced and operational work is under control. They struggle when all three categories arrive as emergencies.

Do not convert story points into headcount. Story points belong to one team and one estimation habit. Count deliverable slices instead: a payment retry rule behind a flag, a support search that works on one entity, or a recovery procedure tested against a copy of production. Small slices reveal whether work can move independently. DORA’s research argues for reducing batch size because smaller changes improve feedback and delivery performance. That supports an internal team only if the business will let the team release in small pieces.

Mark each month as base demand, likely demand, and optional demand. The two engineers must be able to deliver the base work and absorb normal production duties without permanent overtime. Likely work can consume the remaining capacity. Optional work waits. If the plan requires every item in all three columns, the plan does not support two people.

Seasonality matters. A retailer facing a holiday peak, an accounting product approaching a filing deadline, or a marketplace entering a new country may need a temporary concentration of testing and operations. Keep agency capacity or contract specialists through that period. A steady annual average can hide one month that breaks the team.

The switch makes sense when the demand map shows a durable product stream, clear priorities, and enough deferrable work to absorb surprises. If delivery ends after one launch, or if the founder cannot choose which work waits, an agency remains the safer capacity model.

Two engineers need a different operating model

Two AI-augmented engineers can replace much more implementation capacity than their headcount suggests, but they cannot replace undefined ownership. AI can draft code, tests, migrations, documentation, queries, and review notes. It cannot decide which customer risk the company accepts, approve its own production change, or take responsibility for a 3 a.m. outage.

Choose two senior generalists who can each carry work from problem definition through production observation. One may lean toward product and application design, while the other leans toward infrastructure, data, and reliability. Both must read the whole codebase, deploy, inspect telemetry, talk to users, and review the other person’s changes. If either role is limited to handing tickets across a boundary, two people will spend their time waiting.

The field often blurs assisted output and owned delivery. Assisted output is a generated patch, test, or explanation. Owned delivery includes checking assumptions, fitting the change into the system, reviewing security and data effects, deploying it, and watching what happens. The consequence is simple: measure completed outcomes in production, never prompts, generated lines, or pull request counts.

Each engineer needs an isolated way to run AI-generated work, a review path, and explicit limits on what an agent may touch. Production credentials should not appear in prompts or local agent environments. Generated database migrations deserve the same review as hand-written migrations. A fast wrong migration can damage more records before a human notices.

Keep changes small enough for the other engineer to understand in one review session. Require tests for the changed behavior and an observable release condition, such as an error-rate check, business event count, or reconciliation query. AI makes large patches cheap to produce and expensive to verify. That is why accepting bigger batches after adding AI is backwards.

The pair also needs protected time for system care. Reserve capacity for dependency maintenance, flaky test removal, runbook checks, and deletion of dead code. Agencies often hide this work inside retainers or postpone it until a renewal. An internal team sees the debt daily, but a packed feature plan can still force them to ignore it.

Two people are a good unit when both can own delivery, review each other, and use AI to shorten implementation rather than to avoid thinking. If you can only hire one senior engineer and one ticket taker, keep more outside support until the second person can operate independently.

Repository ownership must move before the team

The company should control the repository, cloud accounts, domains, package registries, CI/CD, monitoring, secrets, app-store accounts, and vendor billing before it ends the agency relationship. A ZIP archive of source code is not repository ownership. Control means company administrators can grant access, revoke access, inspect settings, restore service, and pay every required vendor without an agency account.

I have seen handoffs stall because a founder possessed the code but not the system around it. The agency’s personal account owned the repository. A former contractor owned the mobile signing certificate. Deployments called a package from a private registry no one had named. Monitoring alerts went to an agency mailbox. The new engineers spent their first month reconstructing access while the roadmap stood still.

GitHub’s repository-transfer documentation makes the distinction concrete. A transfer can preserve commits, issues, pull requests, releases, webhooks, secrets, and deploy keys, but permissions and linked packages can behave differently depending on the source and destination accounts. I agree with using the platform transfer function instead of copying code. I would still inventory every adjacent asset, because transferring a repository does not transfer ownership of a cloud subscription, DNS zone, external registry, or employee knowledge.

Ask the agency to run an ownership session with a company administrator present. Record each system, current owner, billing owner, two company administrators, recovery method, and outside users. Move assets into company organizations. Do not share the agency founder’s credentials or replace one personal owner with the SMB founder’s personal account.

The incoming engineers can check the local repository shape with commands that expose common handoff gaps:

git remote -v
git branch -a
git tag | tail
git submodule status
git shortlog -sne HEAD

The output should show company-controlled remotes, expected release branches and tags, initialized submodules, and recognizable contributor identities. It will not prove that the build works. Pair it with a clean clone on a new machine, then build, test, deploy to a nonproduction environment, and roll back using only company-held access.

Secrets require rotation, not just transfer. Treat every credential available to agency personnel as exposed to a departing party, even when the relationship ends well. Create replacement credentials, update workloads, verify use, and revoke the old values. Keep an access export before and after the change so someone can review what actually disappeared.

Repository ownership is ready when the company can reproduce a release and remove the agency without asking the agency to repair access. Do this before notice if the contract and relationship permit it. Negotiating ownership under deadline pressure is slow and needlessly risky.

Transition cost includes a temporary loss of speed

The full transition cost includes recruiting, overlap, knowledge transfer, account migration, delayed roadmap work, specialist retainers, new tooling, and management time. Comparing an agency invoice with two salaries ignores the expensive months when both models run and neither works at normal speed.

Build the estimate by month, not by annual headline. Use the company’s actual compensation, employer costs, recruiting fees, equipment, AI tools, observability services, and outside rates. Do not insert someone else’s salary benchmark into a board decision. The useful number is cash out during the transition and steady monthly cost after the pair can operate alone.

A practical worksheet should cover five groups:

• Agency delivery, handoff, and any retained specialist agreement
• Two engineers, including employer cost, equipment, and replacement reserve
• Recruiting fees, interview time, AI tools, and engineering services
• Outside specialist work for architecture, security, data, mobile, or design
• Lost delivery plus the founder and manager hours consumed by the change

Put transition-month cash and steady monthly cost beside each group. For lost delivery, use deferred margin or a missed commercial commitment rather than an invented hourly rate.

Model at least three cases: clean handoff, slow hiring, and disputed or incomplete handoff. The slow-hiring case matters because one accepted offer can fall through while the agency notice clock keeps running. The disputed case forces you to price legal review, asset reconstruction, and a longer overlap without pretending goodwill will solve everything.

Count the incoming team’s learning period as a capacity reduction. Reading code is only part of it. Engineers must learn customer promises, manual support work, deployment quirks, data repair history, and which apparently unused integrations still produce revenue. AI can explain code structure, but it cannot recover a conversation that never reached the repository.

Set a break-even condition rather than a break-even date alone. For example: the internal pair can release a normal product slice, resolve a production issue, and perform a rollback without agency action for four consecutive weeks. The exact period can vary, but observable independence is better than declaring success on the agency’s final invoice date.

Payroll savings should remain a result, not the operating instruction. Cutting cost before transferring knowledge produces an attractive month followed by expensive delay. Fund the overlap, accept a temporary reduction in feature output, and judge the change after the internal team owns routine delivery.

Buy specialist access deliberately

Two generalists will not contain every skill an SMB needs, so the plan must name specialist gaps and fund outside access before those gaps become incidents. The goal is to internalize product judgment and daily delivery, not to pretend specialists have become unnecessary.

Review the six-month demand map for work that requires rare depth. Typical examples include a security assessment, payment compliance, a difficult database migration, mobile release credentials, accessibility testing, tax logic, machine learning evaluation, or a major cloud network change. The exact list depends on the product. Do not hire a full-time specialist for one week of known work, and do not ask a generalist plus an AI model to bluff through regulated decisions.

Separate advice, execution, and approval. A database specialist may design and rehearse a migration. An internal engineer should understand the plan, own the application change, and observe the release. A qualified assessor may review a security control. The company still chooses its response and keeps the evidence. This split prevents the outside expert from becoming a new miniature agency that owns an opaque corner.

Purchase named availability, not a vague promise to “call someone.” The agreement should state the type of request, response window, expected artifacts, access method, and who can authorize work. For recurring needs, buy a small retainer or a block of hours. For predictable projects, schedule the specialist beside the roadmap milestone.

Avoid the popular advice to make both engineers cover every specialty. Founders like it because it sounds efficient and removes vendor lines from a spreadsheet. It is wrong when depth affects safety, regulation, or irreversible data changes. Broad engineers should know when to stop, frame the question, and evaluate specialist work. They do not need to impersonate every profession.

The agency may remain one source of specialist help after daily delivery moves inside. Renegotiate a narrow agreement for the people who know the product or for capabilities used a few times each year. Specify that the company owns resulting code, records, and configuration. A smaller relationship often preserves useful history without leaving the roadmap outside.

The internal model is ready when every foreseeable specialist gap has a person, procurement path, and budget. “We will find someone if it happens” is not coverage.

Two people cannot promise continuous incident coverage

Two engineers can run a reliable product, but they cannot provide humane 24/7 primary and backup coverage by themselves. Vacations, illness, simultaneous incidents, and simple fatigue break that promise. AI can collect evidence and suggest causes. It cannot accept the legal, financial, or customer responsibility for an incident.

Start with the service commitment, not an on-call schedule. Define which events require immediate human action, which can wait until business hours, and what the business tells customers. Many SMBs do not need an engineer awake for every warning. They do need good monitoring, safe automatic recovery, and a clear path for the few conditions that can cause material damage.

NIST SP 800-61r3 places incident response across preparation, detection, response, and recovery activities rather than treating it as one person answering an alert. That framing fits a small team. Reduce the number of pages through rate limits, health checks, automatic restarts, guarded deployments, tested backups, and alerts tied to user impact. Then assign the remaining decisions to named humans.

A workable arrangement has one internal primary, the other internal engineer as business-hours backup, and an external escalation path for nights, leave, or specialist failures. The founder or an operations leader owns business decisions such as shutting down a transaction flow or notifying customers. If the product contract promises strict response around the clock, purchase a managed operations layer or keep agency coverage. Do not bury that obligation in two employment agreements.

Test the path before ending the agency contract. Trigger a safe synthetic failure, confirm the right alert arrives, time acknowledgment, use the runbook, and verify the escalation contact answers. Restore from backup in a separate environment. A backup success message proves that a job ran; a restore test proves that someone can recover usable data.

Write runbooks around decisions, not screenshots. State the symptom, user effect, checks, safe mitigations, rollback point, and escalation threshold. Screenshots age quickly. Commands and expected result shapes are easier to check, but they still need an owner and review date.

Coverage is adequate when the company’s promise matches the people and systems actually available. If sales requires continuous response and the budget only buys two engineers, retain outside coverage. There is no AI prompt that turns an exhausted person into a second shift.

Hire for risk ownership instead of framework fit

The first two hires should match the product’s dominant risks and show that they can make sound tradeoffs with incomplete information. Framework familiarity helps them start, but narrow stack matching can select people who implement tickets without owning outcomes.

Give candidates a sanitized slice of the real system during a paid exercise. Ask them to identify uncertainty, propose a small change, explain how they would test it, and name what they would observe after release. Let them use the AI tools they would use at work. You want to see how they verify generated claims, constrain a patch, and notice missing business context.

Look for complementary depth. For a web product with difficult operations, one engineer may bring application and product strength while the other brings infrastructure and data strength. For a mobile product with a simple backend, change the mix. Both still need enough overlap to review and operate the product when the other is unavailable.

Ask for evidence of ownership: an incident they diagnosed, a migration they made reversible, a feature they cut to protect a deadline, or a system they simplified. Press on what they personally decided and what changed after the release. Polished talk about AI tools matters less than a disciplined verification habit.

The company must also provide product leadership. Two engineers cannot compensate for five stakeholders assigning work independently. One person needs authority to order demand, accept scope cuts, and answer domain questions promptly. This can be a founder, product lead, or fractional technology leader, but the role must exist.

Do not hire both people on the assumption that each is permanently available. Document major systems together, rotate release duties, and keep permissions symmetrical where separation rules allow. If one engineer alone understands billing or deployment, the new model has recreated agency dependency inside the payroll.

An SMB is ready to hire when it can describe the decisions the engineers will own, the risks each hire should cover, and who orders the work. A list of frameworks is not a role design.

The overlap must prove independence

Run the transition as a sequence of operational proofs, with the agency still available while the internal pair performs the work. A calendar handoff that ends with a document dump transfers information but does not prove that anyone can use it.

1. Move ownership and billing into company accounts, then inventory agency access.
2. Have the new team build, test, deploy, observe, and roll back from a clean environment.
3. Transfer one active feature and one real support issue while the agency watches.
4. Rehearse an incident and a data restore, including outside escalation.
5. Revoke a test account, confirm removal across systems, then schedule final offboarding.

Use the agency as an observer during the proof, not as an invisible operator. If a deployment succeeds because an agency engineer repaired a pipeline off screen, repeat it. Record every missing permission, undocumented command, and manual decision as a handoff defect with an owner.

One failure pattern deserves attention. The incoming engineer clones the code, runs the documented setup, and finds that a build pulls a private package through an agency token. The agency replaces the token, so the build turns green. Everyone calls the issue fixed. On final offboarding, the replacement token is revoked with the agency account and production fails on the next build. The proper fix is to move or republish the package under company ownership, update dependency references, rotate credentials, and prove a clean build after the agency account loses access.

Keep a signed record of accepted assets and unresolved exceptions. This is operational clarity, not an accusation. A good agency benefits because the acceptance criteria stop the client from claiming months later that an unrelated gap belonged to the handoff.

Set the termination date after the proofs pass, subject to the contract’s notice terms. If recruiting slips, extend delivery selectively rather than rushing an unready pair into production. Paying for another month hurts less than learning during a customer incident that nobody can renew a certificate.

Independence exists when the internal team completes normal delivery and recovery with company access, while the agency observes. Documents support that proof; they do not replace it.

Some SMBs should keep the agency

Keep the agency when work arrives in short bursts, specialist variety dominates, continuous coverage is contractual, or the company cannot manage two senior engineers. Internal employment is not automatically more mature. It moves scheduling, performance, hiring, retention, and technical direction onto the business.

An agency also fits a finite project with a stable specification and little expected change after launch. The client can define acceptance, buy a temporary team, and retain a maintenance agreement. Hiring permanent engineers for a six-month build with no credible backlog afterward creates a different waste.

Keep outside capacity when the product needs several disciplines every week but not enough of any one to justify a hire. A marketplace launch might need application work, data engineering, infrastructure, security, design, and mobile expertise at once. Two generalists plus AI may coordinate that work, but they should not claim all of it.

Management readiness is the awkward test. Senior internal engineers need fast decisions, direct customer context, and honest priorities. If the founder wants fixed bids for every change, changes scope during delivery, and expects a vendor to absorb the variance, employment will expose the behavior rather than cure it.

There is also a middle model: bring product ownership and one or two core engineers inside, then retain the agency for a bounded subsystem, specialist bench, or incident escalation. Define interfaces, repositories, access, and acceptance so the agency supplements the team without controlling it.

Make the replacement only when the six-month demand map supports steady ownership, the company controls its assets, the transition is funded, specialist gaps have contracts, and incident promises have coverage. My Team & AI Audit tests those conditions in five business days and identifies at least $50,000 a year in savings or the $5,000 fee is waived. The useful output is not permission to cut people; it is an operating case that shows what must move first.

If the evidence says keep the agency, keep it and fix the commercial boundaries. If the evidence supports two internal engineers, pay for the overlap and require operational proof. The expensive decision is neither agency nor payroll. It is changing the model while ownership, demand, and duty remain undefined.