Fractional CTO for a Startup MVP: What Founders Actually Need

The first thing I’d ask a founder who wants a fractional CTO for their MVP is to show me what already exists. Not the deck. The repo, a build I can install, and the list of people who have touched the code. Ten minutes in, that list tells me more than the roadmap does, because a startup’s technical problem is rarely the one on the pitch slide. It’s usually a decision somebody made in month two that nobody has written down.

That is what a fractional CTO is for at MVP stage: judgment on a small number of decisions, delivered part-time, before the expensive ones get made by default. Not a second pair of hands on the keyboard, and not a title for the investor deck. Here is what I think founders actually need from that role, drawn from shipped apps where I was the one asked to make the call.

Diagnose before you build

The clearest case I have is Stanley by Neiman Marcus. A US retailer’s React Native team was stuck on native-UI integration, and that blocked the iOS launch. I came in as an outside technical assessor, and the deliverable was an architecture roadmap, not code. The app is live on the App Store today.

The judgment call that mattered was telling them what not to rebuild. The obvious move for a team stuck on native integration is a from-scratch native rewrite, and it was the wrong move here: reusing what already worked got them to launch. The assessment was mostly an inventory of which parts were fine, which were the actual blocker, and which were merely ugly. Ugly code that ships is a different category from code that blocks you, and a stuck team tends to lump them together.

If you’re a founder with a stuck MVP, this is the first thing to buy. Not a plan to build more, but a written answer to “what is actually blocking us, and what can we leave alone.” An assessment like that costs days. A rewrite decided without one costs quarters.

Validate cheaply before you commit

The second thing an MVP needs is someone who pushes back on the maximal version of the feature. At eBay, the question was whether AR was worth investing in for high-ticket browsing, with unproven ROI. I directed a cross-discipline team to ship a focused AR proof of concept against the real use case, not a full product. It validated AR for high-ticket browsing and unlocked the next phase of investment.

The point was to de-risk the decision, not to build the biggest thing we could justify. A proof of concept is only cheap if it can fail. If nobody agrees in advance what failure looks like, it turns into a slow-motion product build with a “PoC” label on it.

I’d do one thing differently now. I’d instrument that proof of concept with a success threshold agreed before the first line of code, so the go/no-go was mechanical. A go/no-go that depends on people agreeing in a room is fragile, and a founder who is also deciding whether to spend the runway needs a number, not a mood.

Set the review bar for whoever builds

Most MVPs are built by a contractor, an agency, or one or two early hires, and the founder can’t judge the output. That is the classic gap a fractional CTO fills: someone who reads the pull requests, sets the standard, and says which corners are acceptable this quarter.

You don’t need to read every diff. You need a review bar written down, a short list of things that must not merge, and someone accountable for holding it. I’ve written about how this works when the reviewer is partly an agent in how we cut code review time with Claude Code agents, and the finding transfers: the value is in encoding what “good” means for this codebase, not in reading faster.

The same goes for AI-generated code. If your contractor uses coding agents, the output is the average of the internet, and in my experience that average is worse in Swift, where there’s less training data to average over. A short, opinionated instruction file for the repo goes a long way, and I covered what belongs in it in CLAUDE.md for an iOS team. Whoever is acting as CTO should own that file.

Don’t build for the twentieth customer

MVP-stage founders often get advice that sounds senior and is wrong for their stage: design for scale, abstract the integrations, build the platform. I’ve made this mistake myself. On the Aequus Ads SDK I built a mediation abstraction so that adding the next ad network would be cheap. It was the right call for a product that ended up integrating 20+ networks, and it contributed to a +32% lift in ad impressions. It was also over-built: two of the adapters I wrote were never used.

For a startup that hasn’t found its first hundred users, that lesson should be sharper. Build the abstraction when the second integration arrives, and add networks, screens or tenants on real demand. A CTO who tells a pre-product-market-fit team to plan for scale is spending the founder’s runway on a problem the company might never have.

Know which decisions are expensive to undo

Cheap-first is a rule about most decisions, not all of them. A small number of choices are costly to reverse: the data model, the auth approach, the boundary between what’s shared and what’s per-platform, whether the app is one target or several. Those are worth a real conversation, because getting them wrong doesn’t hurt in month two. It hurts in month eighteen.

I wrote about the version of this that comes up in mobile in choosing SwiftUI or UIKit for a team, and the pattern is the same at MVP scale. Start from the constraints of the team you have, write the decision down with the reason, and leave yourself a way to revisit it. If the code needs restructuring later, modularizing without stopping delivery is possible, but it’s far cheaper when the first boundaries were drawn on purpose.

What I got wrong

On the Stanley engagement I should have gotten the client’s constraints in writing on day one. Getting them in writing early would have saved the team a week of wrong-direction work.

The lesson applies from the other side too. If you’re hiring a fractional CTO, ask them to write the constraints back to you in the first week: budget, deadline, who decides, what’s off-limits. Any gap between what you said and what they wrote down is cheap to fix now and expensive to find in month three.

When you don’t need one yet

If nothing has been built and the idea hasn’t been tested with a customer, a fractional CTO is the wrong purchase. You would be paying for leadership over work that doesn’t exist. Build the smallest testable thing first, with a senior engineer or a build partner you trust, and hire technical leadership when there is a codebase, a team, or an investor asking hard questions. At that point the role earns its fee, because there are real decisions to make.

A short checklist

If you’re evaluating this for your own MVP, these are the checks I’d run in the first two weeks:

1. Can someone other than the CTO explain the three most expensive-to-reverse decisions and why they were made?
2. Is there a written review bar, and has a pull request actually been blocked by it?
3. Does every proof of concept have a pass/fail threshold set before it starts?
4. Did the assessment name at least one thing to leave alone?

If the answer to all four is yes, the engagement is working. If not, you have a very expensive advisor.

If you’re at the stage where your MVP is stuck, half-built or about to be rewritten, that’s the kind of call I help teams make. The work page describes how I work with teams.

What’s the decision in your codebase that you suspect was made by default, and never actually made?