The Code Looks Fine. That's the Problem.

Earlier this year, a founder asked me to be their fractional CTO. They’d built the product with Claude, paid a couple of engineers a one-off to tape it together, and launched. A few hundred users. After a few conversations and a quick audit, I declined the engagement. The growth didn’t justify either a technical team or the cost of re-architecting. The code was fine — not elegant, not scalable, but structurally honest for the stage they were at. I told them to keep going and call me when they hit a few thousand daily active users.

That was the easy case.

A different engagement, a few weeks later, looked almost identical from the outside. Founder-built codebase, AI-assisted, launched, users. The code was clean — consistent naming, reasonable structure, tests that passed. Someone who knew what they were doing, or at least someone whose AI tools did.

Then I did the audit.

What I found were subtle issues — not the kind that crash on a Friday afternoon, but the kind that fail at scale. Shortcuts that were invisible unless you’d seen them break before. Architectural tradeoffs that were mediocre rather than wrong — the sort a senior engineer would have debated for an afternoon and resolved differently. Nothing required an immediate fix. Everything would need one eventually.

The conversation surprised the founder. They expected either “it’s great” or “it needs to be rebuilt.” What I gave them was “it depends”.

The quality illusion

This is the central problem in the CTO-founder relationship now, and it is genuinely new. Not because founders are building prototypes — they’ve always done that, with Rails, with WordPress, with Claude. What’s new is that the prototypes no longer look like prototypes.

AI-generated code passes linting. It has consistent naming conventions. It handles the happy path. Sometimes it even has tests — tests that Claude wrote, that pass, that cover exactly the scenarios Claude anticipated and none of the ones it didn’t. This is not unique to AI-generated code, but AI makes it easier to overlook. On the surface, a codebase built over a weekend with Cursor can look indistinguishable from one built over a month by a competent engineer.

The structural gap hasn’t closed. Error handling for edge cases, migration strategies, security decisions, architectural choices that survive ten times the current traffic… these are either still absent, or worse — present but wrong in ways that only show up later. But you can’t see that gap from a code review of the happy path. The code has to be stressed, traced, and questioned before the fault lines appear.

This is harder for a CTO to navigate than obviously bad code. Bad code is easy. You point at the problems, the founder can see them, the conversation is straightforward. Code that looks good but has structural weaknesses requires the CTO to explain invisible risks to someone who — reasonably — can’t easily see them. And who built the thing themselves. And who has users to prove it works.

“Make it production-ready”

The most common version of this conversation starts with a request that sounds technical: “We need to make it production-ready.”

It is not a technical request. What the founder is asking is: validate that my time was not wasted. They may not know that’s the question. I’ve spent months on this. I built something real. Tell me we’re building on it, not starting over.

The CTO who leads with “sixty per cent of this needs rewriting” in the first week has lost the relationship. Even if it’s true. A better first question is: how much runway do you have?

With four months of runway, you don’t rewrite anything. You add monitoring. You fix the security issues that would make the news. You write the three tests that cover the revenue-critical path. You ship, and you buy time.

With eighteen months, you can do the harder work. But even then, you don’t frame it as a rewrite. You frame it as: here’s what we keep, here’s what we wrap, here’s what we replace over time. The founder should see their product evolving, not being discarded. The intelligence embedded in the generated code — the product decisions, the user flows, the understanding of what matters and what can be faked in the early days — survives any rewrite. The code is disposable. The thinking is not.

What production-ready actually means

The gap in the “make it production-ready” conversation is that production-ready has no shared definition between a founder and a CTO. The founder means: it shouldn’t fall over if TechCrunch writes about us. The CTO means: secrets management, observability, deployment pipeline, database migration strategy, rate limiting, error handling, audit logging, and a dozen other things that Claude never raised because nobody asked. Or worse, addressed as an afterthought — and it shows.

The first useful act a CTO can perform is to build that shared definition jointly. Not a list of everything wrong — a prioritised map of what matters now, what matters at the next stage of growth, and what can wait. The founder’s input is essential here because they know what the next stage of growth looks like and the CTO doesn’t.

And I think this is the part most advice on this topic skips. The founder is not a passive recipient of your technical judgement. They are the only person in the room who knows what the product needs to do next, which customers are arriving, what the sales pipeline looks like, and where the growth is coming from. A CTO who assesses the code without trying to understand the business is just an expensive auditor.

When not to rewrite

The hardest discipline in this work is knowing when to leave the code alone.

A codebase serving a few hundred users, built on boring technology with a simple data model and straightforward flows, does not need re-architecting. It needs monitoring, a deployment pipeline, and (most likely) a security review and hardening. The CTO who recommends a rewrite because the code offends their engineering sensibilities is spending the founder’s money on their own aesthetic preferences.

The engagement I declined earlier this year was exactly this. The code was functional, structurally simple, and appropriate for the stage. The founder’s money was better spent on growth than on engineering. Telling them that was more valuable for the business than anything I could have built at that point in time.

The CTO’s job is not to make every codebase beautiful. It is to make the right call about what the codebase needs to survive the next twelve months — and sometimes, that call is: nothing. Keep going. Call me when the problems are real.

The real job

The quality illusion works both ways. Sometimes the code that looks fine isn’t — the structural weaknesses are there, invisible from the surface, waiting for scale to expose them. Sometimes the code that looks fine genuinely is — for now, for this stage, for this number of users.

The old advice about working with non-technical founders was: learn to translate. Bridge the knowledge gap. That advice assumed the founder had no technical knowledge and the CTO had all of it. In 2026, the founder has built something. They have opinions, albeit not always correct ones. They have users. They have code that passes the visual test. The knowledge gap didn’t disappear — it changed shape. The founder knows the product, the market, the user. The CTO knows what breaks under load, what the security surface looks like, and what “production-ready” actually costs. Neither knowledge is complete without the other.

The CTO who dismisses the founder’s code dismisses the product thinking embedded in it. The CTO who accepts it uncritically ships problems they could have caught. The job is neither — it is honest assessment, delivered with respect for what was built, in service of a business you are still learning to understand.

Sometimes the honest assessment is that the founder doesn’t need you yet. Say so.