Publication date:
Publication from:
A few months ago a client came to us with a request that looked fairly typical at first glance: move an application to production-ready infrastructure, sort out compliance, and prepare a go-live plan. The idea was strong, the market was real, and the first users had already validated demand.
But there was a nuance that changed my whole approach to the conversation. The product had been built by one person — no technical co-founder, no CTO, no engineering team. The entire application had come together in a few weeks on a no-code/AI platform. The founder wasn’t an engineer. The founder wasn’t from tech at all.
When a technical founder or CTO comes to us for a consultation, we speak the same language: “infrastructure,” “BAA,” “managed Postgres,” “encryption at rest” — terms both sides of the conversation operate with. But when the person across the table is a founder who genuinely doesn’t understand why something that already looks good in a demo for early users isn’t the same as a system ready to handle real people’s payment or medical data, the entire consulting process has to be built differently.
And there will be more clients like this. Significantly more.
Before talking about how to consult clients like this, it’s worth honestly looking at how serious the underlying problem actually is — because the numbers here are striking even to people who’ve been in the industry for a long time.
Based on several independent industry breakdowns, of the roughly 10,000 startups that shipped applications built primarily through AI code generation into production by the end of 2025, more than 8,000 needed partial or full rework by mid-2026 — in other words, rescue engineering, which is already becoming its own category of service, priced at $50,000–500,000 per project (Vexlint, “Why Vibe Coded Startups Are Failing”; methodology and details — Getcreatr, “Vibe Coding Technical Debt”).
The reason isn’t that AI writes bad code on its own. A Veracode report testing more than a hundred language models on 80 coding tasks found that 45% of the generated code fails basic OWASP Top-10 checks — not exotic vulnerabilities, but basic things like unvalidated input or missing authorization (methodology and results reviewed by Axis Intelligence and Keyhole Software). A study by CodeRabbit and CSA Labs, which analyzed nearly 470 real pull requests, found roughly a 2.7x higher vulnerability rate in AI-generated code compared to equivalent human-written code (same Axis Intelligence source). And an independent scan by the security company Symbiotic Security, which checked 1,072 real vibe-coded apps, found at least one vulnerability in 98% of them — mostly exposed Supabase access keys in client-side code and misconfigured CORS (full Symbiotic Security report).
There’s another pattern, well described by Google Chrome DevTools engineer Addy Osmani back in late 2024, and it’s only been confirmed since: a non-technical person with an AI tool quickly gets to roughly 70% of a working solution, and the last 30% turns into a cycle where every fix creates a new bug (Coding With Vibe). The industry already has a name for this — the “Month Three Wall,” the point where several features, each built in isolation, start structurally diverging from one another.
This is exactly the gap between the feeling of speed and actual speed. A randomized controlled trial by METR involving 16 experienced developers working on large codebases (averaging over 1 million lines of code, 5+ years of experience on the project) with AI assistants found that they actually completed tasks 19% slower, while after finishing the study they estimated that AI had sped them up by 20% (METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”). A gap of nearly 40 percentage points between perception and reality. This is exactly where the unrealistic deadlines that later land on a consultant’s desk come from.
At the macro level, it looks like this: Forrester forecasts that by the end of 2026, more than 75% of technology leaders will carry moderate or severe technical debt, up from just over 50% in 2025, and analysts explicitly name AI-accelerated development as one of the drivers of that jump (official Forrester release). McKinsey, in its “Tech debt: Reclaiming tech equity” research, estimated that technical debt takes up to 40% of an average organization’s technology estate, and that companies spend an additional 10–20% of budget on top of any project’s cost specifically to service that debt (McKinsey, “Breaking technical debt’s vicious cycle”).
Another illustration of this same story — a thread on the Ukrainian developer community forum DOU titled “The Illusion of Savings: Why Replacing Developers With AI Is a Path to Technical Default,” which gathered more than 230 comments: experienced maintainers of large open-source projects there warn directly that the strategy of “keep only senior engineers with AI and cut the rest of the team” is self-deception, because the resulting team ends up more expensive, slower (while being convinced of the opposite), and generates twice as much legacy code (discussion on DOU). This echoes METR’s finding almost word for word — just in practitioners’ language rather than researchers’.
There’s another shift worth understanding, because it’s part of where this debt comes from today: in 2025, AI tools mostly helped an individual developer — autocomplete, suggestions, quick fixes within a single line or function. In 2026, agents increasingly plan, generate, test, and prepare releases on their own with minimal human involvement, working across the entire development cycle rather than a single fragment of code. Gartner forecasts that 40% of enterprise applications will have built-in task-specific AI agents by the end of 2026, up from less than 5% in early 2025, and according to Gartner’s Hype Cycle 2026, more than 60% of organizations plan to deploy such agents within the next two years (official Gartner release).
The productivity gain from this is real, but nowhere near what the “10x” marketing rhetoric promised. Research firm DX, which tracked more than 400 companies over 15 months, put it directly in the title of its report: “AI productivity gains are 10%, not 10x” (DX Research). A systematic review of 116 studies also finds a gain in the 10–30% range for release output, not a multiplier (evidence review — Reinvently).
It’s telling where the bottleneck has moved. A Sonar survey of more than 1,100 professional developers in 2026 found a striking gap: 96% of them don’t fully trust AI-generated code, yet only 48% always review AI-assisted code before committing (Sonar, “State of Code Developer Survey 2026”; results reviewed by Hyrax). In other words, distrust is nearly universal, but the discipline of checking is only present in about half the cases. The hardest part of development in 2026 isn’t code generation — it’s governance: understanding exactly what the AI generated, why, and whether it’s safe to ship to production. And this is exactly the layer of work that’s easiest to skip when the founder isn’t technical.
For a non-technical founder, this is nearly impossible to evaluate on their own — simply because governance is a layer of work the founder has never seen and never learned to judge, even back when humans were writing the code themselves.
It’s easy to assume that consulting a non-technical client is the same job as consulting a CTO, just with less jargon. That’s not the case. The difference isn’t in vocabulary — it’s in the structure of the conversation itself.
First, the shared basis for verification disappears. When we talk to a client’s engineer, they can check our reasoning — ask a clarifying question, push back on a trade-off, notice when we (or they) are oversimplifying at the expense of accuracy. With a non-technical founder, that safety net is gone. They either trust us completely, or they have nothing to lean on to verify that trust. This raises the bar of responsibility on our side, and at the same time makes every recommendation we give potentially opaque to the client.
Second, requirements are framed in business terms rather than technical ones, and those terms keep shifting. In our case, the go-to-market strategy changed mid-discussion: the client initially planned to sell to healthcare organizations (B2B), which immediately triggers full HIPAA compliance, since healthcare institutions in the US are covered entities handling protected health information. Then the focus shifted to selling directly to end consumers (B2C), and the legal context around the exact same technical decisions changed completely. A technical partner usually sees the link between “sales model → regulatory requirements” right away. A non-technical founder doesn’t — and that’s normal: it isn’t their area of expertise.
Third, a product built on an AI platform creates an illusion of completeness: it works, it looks finished, it has an interface — and the founder genuinely doesn’t understand why “finishing it up a bit” costs as much as the entire first version did. The statistics above explain exactly why: the first 70% of a solution and the last 30% are fundamentally different kinds of work in terms of complexity, even though from the outside that difference is barely visible.
We’re not the first to run into this problem, and the industry has already started shaping a response to it — though still in a fragmented way.
The most visible direction is fractional CTO services. Essentially, this is a layer between the business and the engineering side — a person or small team that takes on the job of translating technical decisions into business logic: risk, cost, timelines, rather than architectural detail. The founder doesn’t need to understand how the technology works; they need to understand the risk they’re taking on and how each decision affects the business.
A second direction has emerged over roughly the past year — individual agencies have started offering “vibe coding cleanup” or “rescue engineering” as a standalone service: an audit of generated code, an assessment of architecture, security, and CI/CD readiness, followed by a stabilization plan. At an estimated market scale of $400 million to $4 billion, this has stopped being a niche service and is turning into its own category. Tellingly, these agencies almost always offer a free initial assessment — precisely because at this stage the founder can’t yet formulate the technical scope themselves, and selling a paid audit “blind” wouldn’t be fair to the client.
Drawing on our own experience (and, honestly, a few bumps along the way), we’ve gradually shaped a few principles for working specifically with founders who don’t have a technical background.
Structured discovery instead of free-form conversation. With a technical client, you can improvise — both sides know the territory and can steer the conversation where it needs to go. With a non-technical founder, improvisation is risky: it’s easy to miss a critical question simply because it feels obvious to an engineer and would never occur to someone without an engineering background. A pre-built list of discovery questions, grouped by topic, helps a lot: compliance posture, data scope and type, current environment, target architecture, access and audit, migration plan, integrations, post-launch operations, budget and timeline, success criteria.
Translating technical decisions into business consequences, not technical alternatives. There’s a big difference between the question “AWS or Supabase?” and “launch faster now without full compliance, or launch later fully ready for B2B deals with healthcare organizations.” The founder can’t meaningfully evaluate the first question. They can evaluate the second, because it’s already a question of their business strategy, not architecture.
Written artifacts instead of verbal agreements. A non-technical person forgets the nuances of a technical conversation far faster than an engineer does. That’s why we make a point of documenting every architectural decision in a document or diagram the founder can come back to a week later and still follow the logic.
Explicit management of requirements drift. If requirements can change mid-project — and in work with early-stage startups they almost always do — that needs to be built into the process rather than treated as the plan falling apart. In our case, the shift in the sales model (B2B → B2C) became the basis for a two-phase compliance strategy: launch now without full HIPAA compliance, and activate it once the company actually starts signing agreements with healthcare organizations. That decision didn’t come from having planned everything in advance — it came from a process that allowed replanning without it feeling like “everything broke.”
Vibe coding hasn’t eliminated the need for engineering discipline — it’s raised the price of not having it, because now it’s far easier to generate far more code, far faster, before anyone notices that discipline is missing. For us, this comes down to one practical point: a client without a technical co-founder isn’t a less serious client — they’re a client who needs a different way of working: structured discovery, translating decisions into business consequences, and written artifacts instead of verbal agreements.
We deliberately train this as a skill across the team rather than carving it out into a separate role — for now. The number of “one-person AI-built” startups is growing faster than the industry is figuring out how to work with them properly, so I suspect this question will become sharper for all of us within a year or two. If your team has already settled on a different approach, I’d be glad to compare notes.
Fedir Kompaniiets — CEO & Co-Founder, Gart Solutions. Cloud Solutions Architect & Digital Transformation Consultant.
