First technical hire after agency build: take back control

Why the handoff feels broken

The first surprise after an agency build usually is not the code. It is ownership.

A founder may have the repository, the invoices, and the hosting account, yet still need one agency engineer to push every release. That means the business depends on a person, not a process. If that person is busy, on vacation, or simply gone, even a small change can sit for days.

Product knowledge is often in worse shape than the infrastructure. Pricing rules, user roles, edge cases, and quiet workarounds tend to live in chat threads, calls, voice notes, and old task comments. The app behaves a certain way for a reason, but nobody wrote the reason down. A new engineer can see what the system does. They usually cannot see why.

That gap makes easy work feel slow. A founder asks for a text change or a billing tweak. It sounds simple, but the engineer has to trace hidden logic, ask the agency what happens in production, and wait for someone else to deploy. A task that should take 20 minutes turns into two days of messages.

Nobody set out to create that mess. Agencies often focus on shipping features fast, and many founders are not in a position to demand cleaner docs, safer deploys, or shared product notes. The result is the same: the company owns an app, but not the ability to change it with confidence.

What the first hire should own

The first job is not a new feature. It is control.

For most companies, the first technical hire needs to take over three things right away: access, deployments, and a plain language map of what the product actually does.

Start with a full inventory. Gather every code repo, hosting account, DNS provider, database, storage bucket, email tool, analytics account, app store listing, payment account, and error tracker. Put the owner, login method, billing contact, and recovery method in one shared document.

Four questions reveal most of the risk:

• Who owns the domain, DNS, cloud account, and production database?
• Which repo and branch deploy to production?
• Where do secrets live, and who can rotate them?
• Can the team restore the app from backup today?

If a former vendor still controls the domain or the root cloud account, fix that first. A founder should never need permission from an outside team to ship, roll back, or pay an invoice.

Then write down the app's main jobs in simple words. Skip the architecture diagram for now. Describe the flows that keep the business alive: how users sign up, how they pay, what emails go out, which admin actions matter, what runs on a schedule, and what sends support into panic when it fails.

Set one clear goal for the first month: the company can deploy safely without the agency, recover from a common failure, and explain the product without guessing. That beats a rushed rewrite every time.

Start with access, backups, and risks

Before anyone changes code, the company needs control of the basics. If the agency still owns the cloud account, release pipeline, or email system, you do not fully own the product.

The first few days should look boring. That is fine. This is the work that stops a small surprise from turning into downtime, a billing problem, or a locked account.

Move passwords, tokens, and admin logins into a shared vault the company controls. Include source control, cloud hosting, domains, DNS, databases, storage, CI, and third party tools. Use named accounts where possible. Write down any access that is missing and who needs to fix it.

A quick review usually exposes the weak spots: production hosting, DNS, the code repository, the deploy path, database access, backups, app store accounts, email delivery, payment systems, logs, and alerts. Founders often underestimate app store and billing access until something goes wrong. If one agency employee owns Apple, Google, Stripe, or the mail sender account, fix that early.

Take fresh backups before you clean up infrastructure, update packages, or remove old servers. Export the database, copy uploaded files, and save config details that would be painful to rebuild by hand. Then test one restore in a safe environment. A backup only matters if it restores.

You also need visibility right away. Set up logs, error tracking, and a few simple alerts for downtime, failed jobs, payment issues, and spikes in server errors. Perfect monitoring can wait. Finding a problem within five minutes cannot.

Hold off on risky changes for a few days. No big refactors, no server move, no schema rewrite. That short freeze gives the new hire room to separate access problems from product problems.

If the founder wants proof of progress, send a short risk report at the end of week one. List what the company now controls, what still depends on the agency, and what could break next week if nobody acts.

Map the product before changing code

The fastest win is not a new framework. It is a clear map of how the product works today, who touches it, and where it can fail.

Start with the user paths that make or lose money. Trace what happens from sign up to payment, from login to the main action, and from support request to resolution. Do this in the live product, not from old tickets or stale agency docs.

As you test each flow, write down four things: what the user expects, what the app actually does, which outside service gets called, and whether a human steps in behind the scenes. That last part matters more than most founders expect. Agencies often keep small manual fixes alive for months, and nobody notices until the contract ends.

A useful product map shows the main user journeys, every outside tool or scheduled job they depend on, the admin actions that happen outside the app, and the places where the team promises one thing while the product does another.

Those gaps explain a lot of post handoff panic. A founder may believe the app has automated billing, self serve onboarding, and weekly reports. Then the first hire finds that Stripe charges customers, but failed payments get handled by email, onboarding stalls until someone at the agency clicks through setup, and reports come from a spreadsheet a person updates by hand.

Pick one real customer action and trace it end to end. If a user upgrades a plan, where does that event go? Does it change permissions in the database? Does it trigger an email? Does anyone get notified? If the webhook fails, who notices? One exercise like that often reveals more than a week of reading code.

This map also protects the team from the classic rewrite trap. Once you know which parts users rely on every day, you can leave stable code alone and fix the fragile edges first. That is usually cheaper, safer, and faster than replacing everything because it looks messy.

Recover deployments without drama

Write down the current release process exactly as it works today, even if it feels awkward. Which branch goes live, who clicks the button, where logs live, how database changes run, and what usually breaks should all be on paper.

Then do one staging release with the old process before changing anything. That gives you a baseline. It also tells you whether the real problem is the product, the hosting setup, or missing knowledge from the handoff.

Secrets create some of the worst surprises. Put API keys, database credentials, email settings, storage tokens, and other environment variables in one controlled place. Check which ones still work, which ones nobody understands, and which ones still belong to the agency.

Use a simple rule: two people should be able to deploy without guessing. If only one agency laptop can push a release, you do not have deployment ownership yet. The new hire and one other trusted person should be able to follow the same steps and get the same result.

Before the next production release, test one rollback on staging. Deploy a recent build, then roll back on purpose. You want proof that rollback works, not a vague belief that it probably will.

Teams usually find the same kinds of gaps. The app deploys from a laptop script. The migration step sits in a Slack message. The payment webhook secret lives in one person's password manager. None of that means you need a rewrite. It means you need a cleanup plan.

A 30 day recovery plan

The first month should reduce risk and rebuild control. If a new hire starts with a redesign, they often lose product context, break the release flow, and create a rewrite by accident.

A better plan is simple:

• Days 1 to 3: collect every login, contract, invoice, domain record, cloud account, repo, error tracker, analytics tool, and app store account. Verify ownership. If the agency still controls production, backups, or billing, flag it on day one.
• Days 4 to 10: map the system in plain English. Identify the codebase, the data stores, the services for email, payments, files, and auth, and the rules for each environment.
• Days 11 to 20: turn tribal knowledge into repeatable work. Document support triage, deploy steps, rollback steps, and backup recovery. Run one dry restore and one dry deploy in a safe environment.
• Days 21 to 30: ship one small, real fix. Pick something low risk, move it through review and release, watch the logs, and confirm the result with the founder or support team.

This plan also helps with handoff politics. You do not need a week one argument about code quality. You need access, evidence, and a working release path.

By the end of the month, the company should have a documented system, a safer deploy flow, and proof that the new hire can change production under company control.

Example: a SaaS app with agency access

Picture a small SaaS company with paying customers and a working product. The founder owns the brand and the customer relationships, but the cloud account sits under the agency's email. That means the founder cannot see billing, logs, or backup settings without asking for help.

Deployments are just as fragile. One agency engineer pushes releases from a laptop with local secrets, a half manual script, and steps nobody else has written down. When that person takes a vacation, releases stop.

The same pattern appears everywhere else. Stripe uses a personal login. The email sender account belongs to a former contractor. Analytics lives in someone's private Google account. Nothing is fully broken, but nobody inside the company truly owns it.

In that situation, the real job in week one is to move control without breaking the product. A rewrite would only add more risk. Customers do not care whether the stack looks elegant. They care that invoices go out, password resets work, and the app stays online.

So the new hire starts with one rule: transfer access before changing architecture. They list every system tied to revenue or uptime, then move each one into company accounts. After that, they turn the agency's unwritten knowledge into a short handover doc that answers the basics: how to deploy, where secrets live, how to roll back, which jobs run on a schedule, and who gets alerted when something fails.

Then they ship one small bug fix using the new path. Maybe it is a broken invoice email, a typo in signup, or a webhook retry issue. The fix matters less than the proof. It shows the team can deploy safely and recover if something goes wrong.

That is when ownership starts to feel real.

Mistakes that create a rewrite by accident

The most expensive mistake is cosmetic cleanup too early. A new engineer opens the repo, hates the file names, moves things around, and starts replacing patterns before they understand what users actually do. Two weeks later, the login edge case or billing retry rule disappears. Messy code often holds real business rules. Learn the user flows first, then clean up with purpose.

Another common mistake is switching vendors during handoff week. Moving hosting, email, payments, analytics, or CI while access is still incomplete creates fresh confusion on top of old confusion. Keep the current stack stable long enough to collect admin access, backups, secrets, logs, and rollback steps. Ownership comes before upgrades.

Starting a new platform before fixing access is worse. If nobody can reach production, view logs, rotate keys, or restore a backup, a new codebase solves nothing. It only gives the team a second system to worry about.

Weak docs can also push teams in the wrong direction. Agency handoffs often come with thin notes, missing diagrams, and half finished tickets. That does not mean the product is useless. The running app, support inbox, analytics, and production data usually explain more than the docs do.

Founders sometimes promise a rewrite to calm the team. It sounds decisive, but it puts pressure on everyone to throw away working parts before anyone understands them. A smaller promise works better: secure access, recover deployments, document the product, and fix the worst pain first.

Quick checks for the founder

If you want to know whether the company owns the product or only borrows it, ask for proof.

Get the agency, the founder, and the new engineer on one call and walk through a few live checks:

• Can two people inside the company deploy a small change today and roll it back if needed?
• Can the team restore last night's data into a safe environment?
• Can someone explain the five user flows that matter most in plain language?
• Does support know how to trace a failed signup or payment?
• If the agency disappears tomorrow, does the company still control domains, cloud accounts, source code, app stores, email systems, analytics, and payment tools?

One "no" is not a disaster. Three usually point to an ownership problem, not a coding problem.

A small example makes that clear. A SaaS founder may discover that the app runs fine, but only the agency can deploy, the backups sit in the agency cloud account, and nobody can explain why some card payments fail. That company does not need a rewrite first. It needs access, runbooks, and one person who can take control calmly.

What to do next

If you are bringing in the first technical hire after an agency build, resist the urge to redraw the whole system. Pick the few things that must stay stable over the next 90 days and make that list visible to everyone. For most teams, that means logins, payments, customer data, backups, and the current release process.

That boundary changes the work. Your new hire can focus on safety and control instead of spending weeks on a rebuild nobody can finish.

A solid first quarter usually looks plain from the outside. The team documents what exists, moves accounts into company control, confirms backups and recovery, removes single person dependencies, and keeps shipping small fixes. That is how speed returns. Fewer surprises create more momentum than starting over.

If ownership, infrastructure, or deployments still look messy after the first pass, a short outside review can help. That is the kind of work Oleg Sotnikov does through oleg.is: practical Fractional CTO support for founders who need to regain control of a live product without turning the handoff into a full rebuild.

The target is simple. Someone on your side can explain the system, deploy a small change without fear, and recover service if something breaks. Once that is true, you can decide what to rebuild with a clear head.