Taking software in-house after a consultancy build

Taking software in-house after a consultancy build is a planned ending, not a jailbreak: can your team run deploys, fix production, and ship the next change without the partner holding the keys? Ownership on paper is covered elsewhere. This is about operability and handover when eng moves inside.

When in-house is the right next step

Bring it in-house when you have (or are hiring) people who will own the backlog, and the product is stable enough that learning the codebase is the job, not firefighting every Friday. Too early looks like one junior hire against an undocumented estate, or a “we’ll figure deploys out” plan with no staging. I’ve seen founders hire a team into a black box and call it independence. It was just a new hostage situation with payroll and a Slack channel that went quiet at 6pm.

Sometimes keeping a partner for a slice still wins: thin internal team, heavy ops, or a release that needs senior depth you have not hired yet. In-house is a destination. It is not a moral requirement for next quarter, and rushing it can cost more than the consultancy fee you were trying to escape.

What must already be true

Before handover day, the boring truths have to hold. Repos and cloud in your org. Infra described in git, not in someone’s memory. A pipeline your people can run. Staging that lies less than production. One-command local bring-up, or a written path close to it. Docs beside the code: how to deploy, how to roll back, where secrets live, who gets paged, and what “done” looks like for a release. If those are missing, you are not taking software in-house. You are inheriting a mystery with a burn rate.

Eight Mile’s SaaS work is built so leaving is normal: you own code and accounts from day one, handover documents and a walkthrough, we would rather be recommended than depended on, and the walkthrough is part of the job, not an unpaid favour at the end. Soft path when the slice is eng capacity inside your team: software development.

What a real handover includes

Not a zip file and silence. A real handover is time with your new engineers: architecture walkthrough, deploy together, first small change through the pipeline with them at the keyboard. Runbooks for the failures you already know. Named contacts for a short warranty window after. If the partner cannot sit with your team for a day, they did not design for in-house; they designed for renewals.

When staying with the partner still wins

Stay if hiring would leave you thinner on-call than you are today, or if the next six months are mostly product discovery and you need continuity more than headcount. Switch when you have people ready to own the machine and the estate is already operable. Failures: agency-hosted forever; “handover” that is files in an email; hiring into a system nobody can rebuild from a clean laptop. Demand the opposite from day one if in-house is the plan, not as a surprise clause at the end of the contract.

Build for the ending you want

If taking software in-house after a consultancy build is on your roadmap, demand handover-ready delivery from day one, or book a handover plan when your team is hired.

Own the accounts. Run the pipeline. Walk through with your people until they ship one change without you in the room.

If you want a build or handover structured that way, contact Eight Mile and say when you want eng inside and what still only the partner can deploy today.