Technical cofounder search after outsourcing the build

Why this search gets messy after outsourcing

A product can look healthy and still be hard to inherit. The app loads, customers pay, support stays quiet, and the founder assumes the hard part is over. Then a candidate asks who owns the cloud account, who can ship a fix tonight, and where the real source of truth lives. That is usually where the mess appears.

A technical cofounder search gets harder after outsourcing because the product is only part of the job. The new partner is judging control, risk, and how much cleanup sits behind the demo.

Agencies often hold more than the code. They may control logins, deploy steps, vendor accounts, analytics access, DNS settings, and the build pipeline. Sometimes they keep control on purpose. Sometimes the founder never asked for a full handover. Either way, a strong candidate sees a business that depends on people outside the company for basic changes.

That changes the conversation fast. The founder may think they are hiring someone to improve the product. The candidate may see a rescue job with missing passwords, unclear ownership, and release steps known by one contractor.

Custom work for a few paying customers adds another problem. A startup says it sells one product, but the code tells a different story. One client has a special billing rule, another has a private integration, and a third gets a manual workaround that breaks every normal release. Those small deals can quietly define the whole role.

Most experienced builders do not expect perfection. They do expect honesty. If you hide fragile code, private customer hacks, or access gaps behind a polished pitch, the right people lose trust early.

A simple example makes the point. The founder says, "We need someone to lead engineering for our product." After one call, the candidate learns the agency controls production, customer A has a custom branch, and nobody inside the company can deploy. That is a different job.

Good candidates stay when the scope is clear, even if it is messy. They leave when the story sounds cleaner than the codebase.

Start with access and ownership

Chaos shows up fast in access questions. If your repo, cloud account, or domain still sits under a freelancer's login, the search gets harder before the first serious call.

Start with a full account inventory. Write down every service the company depends on: code hosting, cloud, domain registrar, analytics, email, billing, support inboxes, app stores, payment tools, and any third party APIs that keep the product running.

For each account, note what it controls, who has admin rights, and which recovery email or phone can reset access. Mark anything tied to a contractor's personal email. Mark anything paid from a personal card instead of a company card. Move shared passwords into a company owned password manager, then remove old contractors from admin roles after you confirm the handoff works.

Admin access matters more than simple visibility. A founder may be able to log in and still have no power to change DNS, rotate secrets, restore backups, approve invoices, or transfer ownership. Candidates ask about this early because it tells them whether they are joining a business or inheriting a hostage situation.

Recovery access is where founders get surprised. The code may sit in the company Git account, but the recovery email still goes to an ex agency lead. The cloud bill may be paid by the company, but the root account belongs to a developer who left six months ago. Those gaps look small until launch day, a pricing dispute, or a production outage.

Picture a startup that thinks it owns its product because it can ship updates. Then a cofounder candidate finds that the domain, Apple account, and production database backups belong to three different contractors. That candidate now sees weeks of cleanup before any real product work starts.

Fixing ownership does two things. It lowers risk, and it shows candidates that you deal with messy facts instead of hiding them.

Check code quality in plain language

No serious candidate expects perfect code. They want a fair picture.

If an agency or a few freelancers built the product, ask one senior engineer to review the code for a day or two and write a short memo. Skip the rewrite fantasy. Ask one practical question: "What could break our ability to ship and support customers?"

That review should stay grounded. A good reviewer points out where small changes can cause large bugs, where dead code confuses new developers, where tests are missing around sign up, billing, or data imports, and where old packages could cause security or deploy trouble. They should also flag hidden setup steps, hard coded values, and modules that only one past contractor seemed to understand.

Messy code is not the same as risky code. Plenty of startups ship with rough naming, duplicated functions, and ugly files. That is annoying, but it does not always block releases. Real trouble starts when the app depends on one fragile script, one abandoned library, or one custom patch nobody can explain.

A short audit note should make that distinction clear. Separate ugly but workable code from code that blocks releases, slows onboarding, or creates support fires. Call out the few places where a small test suite would cut risk quickly. List the outdated packages or private patches that need attention soon.

A concrete example helps. Imagine the product works for most users, but one large customer has a custom billing flow with special rules spread across six files. The feature may technically work, yet every billing change risks breaking that one account. That is not a style issue. It is a business risk, and a future cofounder needs to know it before they join.

End the review with a short "fix first" list. Keep it brief. Add smoke tests for the money paths, remove dead code around abandoned features, update the oldest packages, and document the modules that break easily. That kind of clarity makes the search easier because serious candidates can judge the job honestly instead of guessing what is hiding in the codebase.

Find special fixes for specific customers

The messiest part often sits outside the roadmap. It lives in special changes for paying customers: a hard coded pricing rule, a script that cleans bad imports every Friday, or a hidden flag that unlocks a half finished feature for one account.

Candidates notice these things quickly. If you miss them during the search, they walk into a role that feels very different from what you described.

Start with support and account management, not the code. Ask who gets special treatment and what the team still does by hand. Top accounts often depend on small habits nobody wrote down, like rerunning a failed sync, editing a CSV before upload, or changing limits in the database.

Then inspect the product and operations for clues. Look for hard coded customer IDs, plan names, or pricing rules. Check for scripts that one developer runs for only one account, hidden feature flags with no clear owner, manual workarounds buried in support notes, and contract promises the product still cannot handle on its own.

Invoices and contracts tell another part of the story. If a customer pays extra for approval flows, custom exports, or unusual service levels, check whether the product actually supports that work. Sometimes the company sells a feature, but the team delivers it with manual effort behind the scenes.

Write down which of these fixes bring in real revenue today. That matters more than whether the code looks elegant. Most candidates can live with ugly code for a while. They get uneasy when a large share of revenue depends on hidden labor and private exceptions.

A simple example: a SaaS company says it supports enterprise billing. After a short review, the founder learns that one large customer gets invoices from the app, but finance still edits tax lines by hand in a spreadsheet every month. That is not a billing feature. It is a person doing product work.

Put every customer specific fix into a short table with four columns: customer, promise, current workaround, and monthly revenue. That gives candidates a clear picture of the real job and shows that you are not hiding the hard parts.

Run a simple audit in one week

You do not need a large consulting project to understand what a new cofounder would inherit. A focused week is enough to expose the gaps that matter. Leave the last day open for follow ups, missing passwords, and awkward calls with old vendors.

Days 1 to 3

Start with access. On day 1, collect every account, contract, and vendor contact tied to the product. That includes code hosting, cloud accounts, analytics, app stores, payment tools, email systems, domains, and support tools. If access depends on the agency founder's personal email or a former contractor's phone, write that down first.

On day 2, map the product in plain language. What are the main user flows? Where does data come in, where does it get stored, and what breaks if one service goes down? Then write the real deploy steps, not the ideal story. If releases depend on one developer running three commands from a laptop at midnight, that is the process.

Use day 3 for the codebase and release flow. You do not need a deep rewrite plan yet. Check whether the code has tests, basic structure, readable naming, and clear setup instructions. Review the last few releases too. If shipping a small fix takes two days of manual steps, a future cofounder needs to know that.

Days 4 to 6

Day 4 usually uncovers the mess agencies forget to mention. List customer specific fixes, special pricing rules, hidden admin steps, spreadsheets that keep things running, and support tasks nobody documented. A lot of startup pain hides here, not in the app screens.

On day 5, sort issues by business risk and repair cost. Separate "could stop revenue this month" from "annoying but survivable." A missing backup matters more than an ugly settings page. A manual invoice export for one large customer may matter more than five small UI bugs.

Use day 6 to turn the audit into a short candidate brief. Keep it to a few pages. Include the current architecture, access risks, release process, customer specific workarounds, top technical debt, and the first 90 day repair plan. Strong people do not expect perfection. They expect honesty.

If you want a second pair of eyes, this is exactly the kind of review a fractional CTO can do quickly. The goal is not to impress candidates. It is to show them the real job before anyone spends a month in interviews.

Turn the audit into a candidate brief

Messy code rarely scares the right person away. Fuzzy roles do.

Your audit should end in a short brief that tells the truth. Think of it as a working document, not a pitch deck. A future cofounder needs to see the product, the mess, and how much room they will have to fix both.

Start with the product in plain words. Skip vendor names unless they matter. Say what the product does, who pays for it, and which parts of the system matter every day. "Web app for clinic scheduling" is better than a long stack dump. After that, add the stack in simple terms: frontend, backend, database, hosting, third party services, and anything unusual.

Then describe the current state without dressing it up. Say what works well enough today, what breaks often or slows the team down, what was built as a special fix for a specific customer, what nobody truly owns, and what looks risky over the next three to six months.

This matters more than many founders expect. A candidate can handle bad code, missing tests, or rough infrastructure if they know the size of the cleanup job. They cannot judge the role if every problem stays vague.

Be just as clear about authority. Say whether this person can change the stack, replace contractors, talk to customers, hire engineers, or reset deadlines. If they will carry the title but still need approval for every real decision, say that now. Many searches fail right there.

Money and time pressure belong in the brief too. Share the runway, the revenue pressure, and any promises already made to customers or investors. If the team has one strong product person but no engineering manager, say so. If support depends on the founder answering technical questions at night, say that too.

A simple brief might say this: the product has 120 paying teams, sign up and billing work, reporting is fragile, two enterprise clients rely on custom logic, and nobody fully owns deployments. The new cofounder can rebuild parts of the backend, hire one engineer next quarter, and join customer calls when technical tradeoffs affect delivery.

That kind of document saves time on both sides. It helps the right person picture the job before the first serious interview.

A simple startup example

A founder named Nina paid an agency to ship her MVP in three months. The app worked well enough to sign a few early customers, so the arrangement seemed fine at first. Then she started looking for a technical cofounder and discovered that the real product was bigger than the app customers could see.

The agency still controlled the practical access. They handled every deploy, kept the main cloud account under their own email, and stored some credentials in their password manager. Nina could view the product and talk to customers, but she could not inspect the servers, change billing, or release a fix on her own.

That made good candidates slow down. A technical cofounder does not want to begin with a guessing game about who owns the infrastructure. If something breaks at 2 a.m., they need to know they can log in, inspect the system, and act.

Then Nina found a second problem. One of her biggest customers relied on a private script outside the app. Every night, that script cleaned a spreadsheet, reshaped the data, and pushed it into the database. The customer thought this was part of the product, but the script lived on a separate server, had almost no notes, and only the agency knew how to restart it.

Now the role looked very different. A candidate was not inheriting just an MVP. They were inheriting an MVP, a hidden customer workflow, and a dependency on an agency for deploys and support.

Nina fixed the basics before she kept interviewing. She moved cloud accounts into company ownership, took control of the code repository, collected the credentials, and wrote down every moving part that touched customer data. She also described that private script clearly in the role brief instead of burying it in a late conversation.

After that, strong candidates moved forward. Not because the system was clean, but because the scope was honest and the founder had already taken ownership of the mess.

Mistakes that push strong candidates away

Most failed searches break down early. The problem is usually not the code itself. It is the gap between the role described and the role waiting underneath.

One common mistake is saving access problems for late interview rounds. A founder says the product is live and the team can "hand everything over," then the candidate learns there is no admin access to cloud accounts, no billing control, or no way to deploy without the old agency. That turns a leadership role into recovery work.

Another mistake is describing a rescue job as if it were a fresh build. If the app already exists, the real work may be untangling rushed code, old vendor decisions, and customer specific patches. Good candidates do not mind hard problems. They do mind bait and switch.

Role design causes trouble too. Offering equity before you define scope, authority, and decision making creates stress fast. A serious candidate wants to know where they own decisions, where the founder keeps control, and what success looks like in the first 90 days.

Interviews can go wrong in a more direct way. Some founders ask candidates to fix production bugs, rewrite modules, or clean up outsourced code for free as a test. Most strong people walk away. A short review, a discussion of tradeoffs, or a paid trial is fair. Unpaid repair work is not.

Picture this conversation. A founder says, "We need a product minded technical partner." In round three, the candidate learns that the agency still owns the repo, one large customer runs on custom logic nobody documented, and support tickets pile up every weekend. That person is not joining a build. They are joining a rescue.

If you want better conversations, show the real state of the product early. Even a short audit by an experienced CTO or advisor can make the role feel honest, which is often enough to keep strong candidates in the process.

Quick checks before interviews

Interviews go better when you can answer a few basic questions on the spot. Candidates do not expect a perfect setup. They expect a clear picture of what they are walking into.

Start with control. If the agency disappeared tomorrow, could you deploy a release, view production logs, and reset passwords for the services that matter? If the honest answer is no, say that early. Hiding it wastes everyone's time.

Then look at what makes the product messy in daily use. Many outsourced builds carry quiet promises made to one or two paying customers. A candidate will want to know which exceptions already exist, how often they break, and whether they belong in the product at all.

Before interviews, make sure you can answer five simple questions:

• Can your team ship a small release without asking the agency for help?
• Can you name the top three customer specific exceptions in the product?
• Can you explain the monthly spend for hosting, tools, and outside support?
• Can you open the code repo, backlog, and basic docs during the call?
• Can you say who makes the final call on product and technical decisions?

Money matters more than many founders think. If your cloud bill is high, explain why. If you pay for duplicate tools nobody uses, say that too. Candidates do not need tidy numbers. They need honest ones.

Access matters just as much. Show the repository, open tasks, and any docs that explain setup, releases, or architecture. Even thin documentation is better than vague answers. If nothing exists, admit it and note who still holds the missing knowledge.

Decision rights often create the most friction. If the founder approves features, an agency lead approves technical choices, and a big client pressures both, the new cofounder inherits a political problem, not just a code problem.

When you can explain all of this in ten minutes, interviews get sharper. Candidates stop guessing and start thinking about the real job.

What to do next

Start with the boring access problems. If a future cofounder cannot see the code repo, hosting account, analytics, error logs, domain settings, billing, and product docs on day one, they are not stepping into ownership. They are stepping into cleanup with one hand tied behind their back.

Keep the audit short. One page is often enough if it shows what exists, who controls it, what is risky, and what can wait. Send that document before deep interviews. Strong candidates usually do not panic over messy code. They walk away from surprises.

Use early calls to test fit. Ask how the candidate would handle the current product, what they would keep, and what they would change in the first 90 days. That gives you a real signal. If the whole call turns into a hunt for missing passwords, unknown vendors, or private customer patches, the role will look worse than it needs to.

A simple checklist helps: close access gaps across code, cloud, domains, analytics, support tools, and payments; write one short audit note with clear risks and urgent fixes; and share that note early so the search starts with facts.

If you want an outside review first, Oleg Sotnikov at oleg.is does this kind of work as a fractional CTO and startup advisor. A quick audit of code, access, and operating setup can help founders separate normal startup mess from the problems that will slow down a serious hire.

The goal is not to make the company look polished. The goal is to make the job clear. When candidates can see the real state of the product and the real scope of the work, the right people stay in the process for the right reasons.