How to manage an outsourced development team without a CTO in 2026

TL;DR

To manage an outsourced development team without a CTO in 2026, replace the missing title with three controls you can set up in a week: a part-time tech lead who reviews every pull request, repository rules that block unreviewed merges, and interview questions that expose engineers who paste code they cannot explain. Go Fractional's benchmark puts the median fractional CTO at $220 an hour, and a weekly review seat needs about four of those hours, so the insurance runs $3,000 to $4,300 a month against a $453,440 annual equivalent for the full-time hire.

• Hire the reviewer before the vendor, with veto power over merges.
• Put the repository, stores and cloud accounts in your name, then let GitHub's protected branches enforce the review.
• Ask every candidate reviewer when their last pull request was merged and in which repository.
• Judge the vendor weekly on artifacts: reviewed pull requests and a build you can install.

Without a technical reviewer, you judge by output, and output lies late

The problem is timing. A nutrition app can look finished on a demo call for six months while the code underneath cannot be extended, tested or handed to anyone else. You find out when you try to change vendors, or when a store rejects the build.

The code your vendor ships is also less human than it was two years ago. In the 2025 Stack Overflow Developer Survey, 84% of developers said they use or plan to use AI tools, 46% distrust the accuracy of AI output, and 45% said debugging AI-generated code is time-consuming. The people writing your app do not fully trust what their own tools produce. Somebody on your side has to read it.

The economics push the other way. Clutch lists most development firms at $25 to $49 an hour, with US shops at $50 to $99. A founder paying $40 an hour for a team of four is spending around $25,000 a month with nobody in the room who can tell a clean pull request from a pasted one. That gap is the subject of this article.

One more thing about the word CTO. A chief technology officer sets strategy, hires and owns architecture. What a founder without technical staff needs first is narrower: one person who reads every change before it lands and tells you, in plain English, whether the thing you are paying for can be maintained. That is a tech lead on a part-time contract.

Two 2026 store deadlines that already tested your vendor

You do not need to read code to run this test. You need to ask two questions.

Since April 28, 2026, Apple has required that iOS and iPadOS apps uploaded to App Store Connect be built with the iOS 26 and iPadOS 26 SDK or later, with matching rules for its other platforms. Since August 31, 2026, new apps and updates on Google Play must target Android 16, API level 36, or higher. An app still targeting Android 14 or lower is shown only to devices on the same or an older Android version; new users on current phones see that the app "is not available to install on their device because it was made for an older version of Android." Google accepts extension requests to November 1, 2026 through the Play Console.

Ask your vendor when they moved your builds to the iOS 26 SDK and to API level 36. A team that did both and told you in advance is doing the maintenance you pay for. A team that hears about either deadline from you has shown you how it handles everything else you cannot see. If the Android answer is a blank look, file the extension yourself today: it is a form in the console, and it buys time until November 1.

How we built this playbook

Four rules, applied to every recommendation below.

• Each control is one a founder can verify without reading code: an invoice, a repository setting, an account owner, an artifact delivered on a date.
• Each number has a public source you can open, or it comes from our own records and is labeled as such.
• Where our own data appears, a pattern counts only when it shows up in at least three statements from two independent sources. Anything thinner is not published.
• Opinions are labeled as opinions. There are several.

One disclosure. Mercury Development is an outsourced development shop, so every control here is one a client should apply to us, including the independent reviewer. The contract side, who owns the code and which accounts must sit in your name, is covered in our ownership checklist and vendor continuity plan. This article covers the people side: who watches the work when you cannot.

The oversight setup at a glance

The part-time tech lead: four hours a week that replace a title

The best data on how much review a codebase needs comes from Google. In the ICSE 2018 study Modern Code Review: A Case Study at Google, Sadowski and colleagues report that Google engineers spend a median of 2.6 hours a week reviewing changes, that the median change modifies 24 lines, that the median reviewer count is one, and that initial feedback on small changes arrives in a median of under an hour. Review at Google is a light, fast, one-reviewer habit. That is the habit you are buying, and one person can carry it for a team of four to six.

Budget from public rates rather than a vendor's quote. Go Fractional, a marketplace for fractional executives, publishes a rolling 90-day benchmark: the median rate is $220 an hour, the middle half sits between $175 and $250, and employers post at a median of $145. Four hours a week at $175 to $250 is $700 to $1,000 a week, roughly $3,000 to $4,300 a month. The same page puts the full-time equivalent of a $218 rate at $453,440 a year. You are renting the one CTO habit that protects your money.

Two rules make the seat work. The reviewer is not employed by the vendor and does not report to the vendor: a vendor reviewing its own code is quality control, which you also want, but it is not oversight. And the reviewer has a veto: no pull request merges without their approval, enforced by the repository, which is the next section.

Opinion: pay the reviewer by the hour for the first three months. A retainer at $11,900 a month, Go Fractional's starting figure, buys advisory time you do not need yet. Hourly review of real pull requests is the only thing that tells you whether the vendor is good.

Code review as insurance against vendor lock-in

Lock-in is rarely a contract clause. It is a codebase only one team understands. The reviewer's weekly reading keeps a second team able to pick it up, because every change is explained to somebody outside the vendor as it is written, and the explanation stays in the pull request.

Make the review mandatory in the repository rather than in a meeting. GitHub's protected branches let a repository administrator "require that all pull requests receive a specific number of approving reviews before someone merges the pull request into a protected branch." Turn on one required approval, name your reviewer as a code owner so their approval is the one that counts, and enable the option to dismiss stale approvals when new commits change the diff. Add required status checks, which "must have a successful, skipped, or neutral status before collaborators can make changes to a protected branch." From that point, a merge without review cannot happen.

This works only if the repository is yours. If the vendor owns it, the vendor's administrator can switch the rules off. Create the organization account and the repository, invite the vendor's engineers with write access and no admin rights, then set the rules. The account-by-account list is in the continuity plan.

What the reviewer sends you each week is a page: what changed, what they blocked and why, and one sentence on whether a new team could take over tomorrow. Read that sentence every week. When it changes from yes to probably, you have found lock-in early enough to fix it.

Automated review tools help and do not substitute. Competing guides, such as NineTwoThree's, recommend SonarQube or Codacy so a non-technical founder can see quality scores. Scores cover style and known bug patterns. They do not say whether the payments module makes sense or whether the engineer who wrote it can explain it. A human reviewer does, and the tools give that human a head start.

Red-flag questions that catch a copy-paste coder

You will interview two kinds of people, the vendor's engineers and your own reviewer, and the tell is the same for both. People who wrote code can talk about a specific decision they made in it. People who pasted it cannot.

For the vendor's engineers, one question does most of the work. Ask them to open a recent pull request of their own, pick one line, and explain what breaks if that line is removed. A working engineer answers in a sentence and usually volunteers a second problem you did not ask about. A copy-paste coder describes the purpose of the code rather than its behavior, and reaches for the file that called it. Follow with a live change: "The customer now wants weekly meal plans instead of daily. Which files do you touch?" Your reviewer judges the answer. You watch whether the engineer needs to look anything up.

For your reviewer, the risk was named bluntly in a public thread quoted in the data section below: hiring a "CTO" who has not coded in ten years. Two questions settle it. When was your last pull request merged, and in which repository? A year or more, or a repository they cannot show you, means an advisor, and you need a reviewer. Then hand them a real pull request from your vendor's repository and thirty minutes. The result is your first review report, and it tells you more than the resume.

Opinion: run the engineer interviews with the reviewer on the call and let the reviewer ask the technical follow-ups. Your job is to watch how the vendor reacts to being questioned by someone who can check. A team that argues about process is telling you where the next argument will be.

Weekly artifacts you can judge without reading code

The vendor's status report is an opinion. Four artifacts are facts, and you can check each in under half an hour.

Merged pull requests with an approval from your reviewer. Count them, read the titles, compare the titles to what you asked for. A week of merges you do not recognize is scope drift with a timestamp.

A build you can install: TestFlight on iOS, an internal test track on Android, a staging URL on web. A demo on the vendor's screen is not a build. A build on your device that carries this week's merges is.

A green pipeline. With required status checks in place, the repository shows whether tests passed on the main branch. You do not need to know what the tests do, only that they ran, passed, and grew in number.

Your reviewer's page: what changed, what was blocked, whether a new team could take over. Over a quarter, those pages are the record that decides whether you renew the vendor.

Velocity charts and story points describe the vendor's process, not your product. Ask for them if they help the team. Do not manage by them.

Which setup fits your situation

Founder with a first build and a budget under $100,000. One reviewer at four hours a week, protected branches, accounts in your name. Skip the fractional CTO retainer: you need someone reading code, not someone writing a technology strategy for a product that does not exist yet.

Operator replacing a failed vendor. Hire the reviewer before the replacement team, and have them audit the code you already own for a week. Their report decides whether the new team continues the codebase or starts over, and that decision should come from someone who does not profit from either answer.

Coaching or nutrition business moving off a white-label platform to an owned app. Data migration and subscription flows are where an outsourced team makes quiet decisions you live with for years. Add reviewer sign-off on the data model and the payment integration as named milestones.

Company with a product in market and a technical hire on the way. Keep the reviewer until the hire's second month. The weekly pages are the fastest onboarding document the new person will get.

Regulated data, such as health or payment information. The reviewer needs domain experience, and the rate will sit at the top of the Go Fractional range or above it. This is the one case where the specialist is the cheaper option.

What public buyer discussions show

These are our own observations, from public sources and from our sales conversations. In 2026 we analyzed 9,246 statements from buyer discussions on Hacker News, Reddit and Capterra, filtered them to 261 signals from large-ticket contexts ($50,000 or more in spend, or an explicit enterprise, franchise or multi-location marker) and kept 40 patterns that appeared in at least three statements from two independent sources.

Managing a vendor without technical staff did not surface as a pattern of its own. It surfaces as the condition under which the other patterns happen. The most repeated rescue pattern in the corpus is a founder who has spent a six-figure sum and has "barely anything to show for it", and the advice other buyers give that founder is about oversight rather than price. One states the mechanism plainly: "without someone technical vetting their work, you'll have no choice but to judge by output." One asks the question this article answers: "Is hiring a part-time Tech Lead to do weekly code reviews a good way to prevent vendor lock-in?" One asks for "one red flag question to catch a copy-paste coder." And one names the failure mode of the fix itself, the "risk of hiring a 'CTO' who hasn't coded in 10 years."

Our own pipeline in nutrition and coaching says the same thing from the other side of the table. In those conversations the buyer is most often a founder or an operator with no technical hire, and the trust screen they run on us is about people rather than architecture: are the engineers in-house or subcontracted, and does support continue after launch. Both are proxies for the question they cannot ask directly: who will tell me if this is bad?

Buyers do not plan for oversight. They discover they needed it after the money is spent.

The title is not the control. The review is

Opinion, stated plainly. Founders without technical background look for a CTO because the title feels like safety. What protects your money is a habit: nothing merges until someone who does not work for the vendor has read it and can explain it back to you.

A fractional CTO who advises for a day a month and never opens a pull request is an expensive way to feel supervised. A senior engineer on four hours a week with a veto in the repository is a cheap way to be supervised. Most founders buy the first because it answers the question "who is my technical person." Buy the second. When the product grows to the point where you need strategy, the reviewer's weekly pages will say so, and by then you will know what kind of CTO to hire.

Written by Rob Devereaux, Chief Operating Officer at Mercury Development. Rob has run the firm's operations from Hudson, Ohio since 2019 and has over 20 years of operational and financial experience. The staffing and contract terms this playbook recommends are the ones he sets on the firm's own engagements.

Nobody technical on your side of the build? Let us set up the review seat

Tell us where the repository sits, who owns the store and cloud accounts, and whether anyone outside the vendor reads the code today. We come back in writing with the repository rules to switch on, the reviewer profile to hire and the interview questions to ask, whether or not the vendor turns out to be us.