Hiring someone to take over an agency-built product
You don't need a builder. You need an inheritor, and that's a different kind of engineer.
By Macro Merge · · 4 min read
The short version
- 1Builders love a blank page. Inheritors read before they write, stabilise before they improve, and decide what to rebuild without ego.
- 2Before the agency leaves, move every account, repository and password into the company's name.
- 3Ask candidates what they'd leave alone for three months, and why. It separates the two kinds of engineer quickly.
Strong at what?
When an agency or freelancer built your first product, the engineer you need next has an unusual job. They aren't starting from a blank page. They're inheriting a system someone else built, under someone else's priorities, often with little documentation. That calls for a different kind of engineer from the one who loves building from scratch.
Builders and inheritors are different hires
The builder
- Loves a blank page and a fresh architecture.
- First 30 days: proposes a rebuild.
- How it goes wrong here: rewrites too early, and the product stands still for months while customers wait.
The inheritor
- Enjoys understanding a system and making it reliable.
- First 30 days: gets access, reads the code, fixes the worst failures.
- How it goes wrong here: keeps patching forever, and never decides what to rebuild.
Both can be excellent engineers, but only one fits this brief. The best person for this role is an inheritor with the judgement to know when inheriting should end. Someone who reads before they write, stabilises before they improve, and makes the rebuild-or-repair decision without ego.
You don't need a builder. You need an inheritor.
What the first six months actually involve
- Getting control. Access to everything: code, hosting, domains, monitoring and deployments. Many founders are surprised by how much of this sits in the agency's accounts.
- Stabilising. Finding the worst failure points and fixing them, so the night-time outages stop.
- Understanding and documenting. Writing down what exists, how it fits together and where the risks are.
- Deciding. What to keep, what to fix and what to rebuild, in what order. Then explaining it to the founders in plain language, trade-offs included.
- Preparing for the next hire. Making the codebase something a second engineer can join without months of archaeology.
Describe the role like this and you'll attract people who find it interesting. Describe it as “build the next version of our platform” and you'll attract builders.
Before the agency leaves: a handover checklist
Do this while the relationship is still good, and well before the contract ends.
Handover checklist
- All code repositories moved to accounts your company owns.
- Hosting, domain, email and third-party service accounts in the company's name, with billing you control.
- Every password, key and access token changed after the handover.
- Notes on how to deploy and how the infrastructure is set up, even rough ones.
- A written list of known issues and workarounds.
- Backups confirmed by actually restoring one, not just by checking they exist.
- A few paid hours of the agency's time reserved for questions after the handover.
Senior engineer, tech lead or CTO
Founders often reach for “CTO” here, sometimes to attract a strong candidate. Three questions decide the right title:
- Will they hire and lead the next engineers? If so, you're describing a lead, or someone who grows into one.
- Will they own technical strategy, or carry out one you set with an advisor? Owning it is a more senior role.
- What will the equity conversation need to reflect? Titles and equity tend to move together, so be deliberate about both.
Describe the path, not just the title. “A strong engineer now, leading engineering as we grow, if it works for both of us” is honest, and it attracts people who want that path. A CTO title given too early is hard to take back.
What to look for: evidence, not adjectives
- Has inherited a production system and made it more reliable. Ask for the story: what they found, what they fixed first and why.
- Has been on call. They know what it means for something to break at 2am, and they build to prevent it.
- Has explained technical decisions to non-technical people. You'll depend on this every week.
- Shows restraint. Can name things they deliberately didn't rewrite, and explain why.
What to stop prioritising
- An exact stack match. Agency-built products use all sorts of stacks. A strong inheritor learns an unfamiliar one quickly. Reasoning about a messy system is the rarer skill.
- Big-company names. Large companies rarely have systems in this state. Someone from a smaller company or a services firm who has inherited messy code before may be a better fit.
- Enthusiasm for rewriting. It sounds like ambition. In this role, it's often a risk.
- Years of experience as a proxy. Ask what kind of years.
One interview question that works
Share a high-level overview of your system: a diagram, a description of the main parts and the known problems. Remove anything sensitive, or share it under a confidentiality agreement.
Then ask: “What would you leave alone for the first three months, and why?”
- Strong answers start with questions. What breaks most? What do customers complain about? What did the agency say about it? Then they name specific things they'd leave alone because they work, and things they'd fix first because they hurt.
- Weak answers go straight to what they'd replace, often with their favourite technology, before asking a single question.
Timing it right
Aim for an overlap with the agency: ideally a few weeks when your new engineer can ask questions while the people who built the system are still around. Work backwards from the contract end date, and remember that experienced engineers often have notice periods of one to two months. See planning a hire around notice periods.
If this will be your first engineering hire, it's also worth reading what matters in a first engineer.