The New Bottleneck

At first, the demonstration is convincing. The founder moves through a product that did not exist a few months earlier. Payments work. Reports appear instantly. An assistant drafts content, summarizes records, and completes tasks that once required several screens and a fair amount of manual effort. The interface is polished enough that the software no longer looks like an experiment. It looks ready to sell.

Then a prospective customer begins asking questions. How will the system connect to the tools already in use? Where will sensitive information be stored, and who can see it? What happens when an integration fails during a critical transaction? How long will implementation take, and what will employees have to change? The founder can describe the features. The harder task is explaining why the customer should reorganize part of its business around them.

That conversation reveals the distance between an application and a company.

In my work over the past six months, I have watched several early-stage technology companies reach some version of this moment. The founders were serious, and the software was real. In some cases, a very small team had produced a level of polish that would have required far more people only a few years ago. The organization behind the product had developed much more slowly. The customer was still loosely defined. The problem had not been connected to a clear buyer or budget. The route to market was uncertain. Technical and operational obligations had accumulated faster than the company’s ability to own them.

The mistakes themselves are familiar. Founders have always built too early, underestimated distribution, and discovered that a user’s enthusiasm does not guarantee a buyer’s approval. Generative AI adds a new layer of camouflage: weak market research, fragile architecture, and unrealistic financial plans can now sit behind software that looks finished.

Coding agents can produce interfaces, database models, tests, documentation, deployment scripts, and substantial portions of working applications. In capable hands, they eliminate routine work and allow small teams to move with extraordinary speed. That same speed can give an untested idea the appearance of a finished decision. The software may arrive long before the company has gathered enough evidence to justify the assumption beneath it.

High development costs once imposed a form of discipline. Engineering was expensive, so features had to compete for time and money. That constraint frustrated good teams and kept worthy ideas from being tested, but it also forced founders to choose before development consumed substantial resources. They had to decide which problem mattered, whom they were solving it for, and what could wait.

AI has weakened that constraint, leaving teams to supply the discipline themselves. A team can now say yes to nearly every plausible feature. What it needs, more than ever, is a reliable way to decide which ideas should remain unbuilt.

The difficult work of company building has therefore shifted toward questions outside code’s reach. Which problem is painful enough to support a business? Whose behavior must change? What will a buyer pay? How will the product earn trust? Does the company have the expertise and capital to support what it has built? The answers form the product’s foundation.

The Product Before the Product

Before a startup builds software, it builds an explanation of the world. It decides who has a problem, why the problem persists, how people cope with it today, and what might persuade them to adopt a different solution. That explanation may never appear in a repository, but it determines what the repository should contain and whether a demonstration can lead to a contract. The first product of an early company, then, is evidence.

Evidence begins with a problem stated in terms a customer would recognize. “Businesses need better automation,” “health care is inefficient,” and “small companies need AI” point toward broad opportunities, but they do not identify a recurring situation costly enough to make someone seek a different outcome. A useful problem statement names who is affected, what that person is trying to accomplish, what gets in the way, and what the failure costs. That specificity tells founders whom to interview, what a prototype must test, and which result might justify a price. Without it, the team is searching for a problem inside a growing codebase.

Founders often mistake interest for validation. People are generous when discussing hypothetical products, especially when the person asking is visibly excited. A potential user may praise an idea while lacking the authority, urgency, budget, or willingness to change an existing process. “I would use that” is pleasant feedback, but it says little about what the person will do when adoption requires a purchase order, a security review, data migration, training, or a change in established behavior.

That is why useful customer interviews focus on events that have already happened (opens in a new tab). When did the problem last occur? What did the customer do next? Who became involved? What did the failure cost? What has the organization already tried? Who controls the budget, and what other priorities compete for it? Questions about past behavior are more likely than hypotheticals to reveal whether the problem is urgent or merely interesting.

AI can improve this research. It can organize public information, map competitors, prepare interview questions, and analyze transcripts, support tickets, and survey responses. The missing piece is the organizational context in which a purchase is made. In business software, the user may want a faster workflow, the buyer may need measurable savings, and security or operations teams may carry the implementation risk. Studying only the user can produce software the company will not buy; studying only the executive buyer can produce software employees resist. Those objections are part of the product’s design problem.

Customer research and development should move together. Early conversations shape a prototype, which gives customers something concrete to challenge. Their reactions expose assumptions, and the next version tests whether the company has learned anything. Early software earns its keep by revealing weak assumptions while the answer remains inexpensive.

Pricing and distribution belong in the same loop. Commercial validation requires more than users imagining a benefit. The company must understand how buyers evaluate the purchase, what outcome could justify the price, how the product will reach those buyers, and what proof a young vendor must provide before anyone trusts it. Go-to-market begins while engineering is still shaping the product because it influences what gets built, how the product is packaged, and whether adoption creates more risk than it removes.

This work can look slow beside the visible pace of AI-assisted development. In practice, it is often the fastest progress available to a startup. A customer conversation that prevents six months of unnecessary work is faster than any coding agent. A pricing discussion that reveals the intended buyer cannot justify the expense is more valuable than another completed integration. Discovering that a product belongs in a different market, or should be abandoned, can keep a company from compounding an expensive mistake. Few early successes are cheaper or more useful.

Once credible evidence exists, design choices can be tied to observed needs and engineering investments weighed against commercial priorities. The roadmap becomes a sequence of testable bets rather than a catalog of everything the team knows how to produce. The next challenge is building a system that can be trusted when the controlled demonstration gives way to production.

Production Is a Different Product

The growing ability of coding agents raises a reasonable question: If a model can generate so much of the implementation, how much traditional technical expertise does a startup still need?

The answer depends on what engineers are for. If engineering means translating an unambiguous specification into code, AI is already reducing the human effort required. In practice, specifications are rarely complete, business requirements conflict, and important constraints emerge only after a system is used. Engineering also includes deciding how the product should behave under pressure, which trade-offs are acceptable, and who will own the consequences when an assumption fails. That work matters more when implementation can outrun deliberation.

Anthropic offers a useful illustration (opens in a new tab). As of May 2026, the company reported that Claude had authored more than 80 percent of the code merged into its codebase and that the typical engineer was merging eight times as much code per day in the second quarter of 2026 as in 2024. The same account describes the human work surrounding that output: engineers direct and review the work, define goals, handle incidents, and decide which problems are worth solving. The statistic demonstrates how much implementation AI can absorb inside a mature technical organization. It also shows how much experienced judgment surrounds the output.

Broader research points in the same direction. Google’s 2025 DORA report (opens in a new tab) described AI as an amplifier of the organization into which it is introduced, magnifying existing strengths and weaknesses. In Stack Overflow’s 2025 developer survey (opens in a new tab), more respondents distrusted the accuracy of AI tools than trusted it. Their most common frustration was a subtler and potentially more dangerous failure: a solution that was almost right.

Obvious errors are easy to reject. Almost-correct answers can survive a superficial review, enter the codebase, and fail only when customers place demands on the system that were absent from the prompt.

A demonstration rarely reveals production demands. It works with clean data, predictable workflows, responsive dependencies, and simple permissions. Real customers import years of inconsistent records, create complicated access rules, arrive in uneven traffic patterns, and find paths no scripted test anticipated. The system must preserve data through interruptions, expose enough information to diagnose failures, recover from partial outages, and remain understandable to people who did not generate the original code. Customers experience those qualities together, as trust.

Architecture involves a series of decisions made under incomplete and conflicting constraints: moving quickly without making growth prohibitively expensive, isolating customers without multiplying infrastructure costs, and preserving auditability without making every workflow burdensome. Testing and operations carry the same problem. A generated test suite may prove that software behaves as specified without showing that the specification reflects reality. A backup becomes a recovery capability only after someone has restored it. Observability exists only when the team can connect system signals to customer harm.

A startup may need fewer specialists than it once did because capable people can cover a broader range of work with AI. It still needs clear ownership of architecture, data, interfaces, infrastructure, security, quality, and operations. When head count shrinks, the responsibility carried by each major decision grows.

Executive titles can obscure this distinction in very young companies. A founder may legitimately serve as chief technology officer, yet the title alone says little about the judgment the role requires. Technical leadership means owning architecture, delivery, infrastructure cost, risk, and the promises made to customers. A founder does not need every skill in-house. The essential requirement is enough understanding to recognize what is missing, enough humility to seek help, and enough capital to obtain it.

Even a well-designed product is still only one part of a functioning company. The system may be secure, reliable, and genuinely useful while the business around it remains unable to acquire customers, support implementations, or survive long enough to learn.

The Company Around the Code

The falling cost of development creates another tempting conclusion: If one person can now build what once required several engineers, perhaps the company itself can be funded like a software subscription.

Lower development costs change startup economics, sometimes dramatically, while leaving many other expenses intact. A company still has to acquire customers, protect data, pay for infrastructure, maintain integrations, negotiate contracts, provide support, and operate while revenue remains uncertain. An early company can combine roles, use contractors, and postpone work that does not yet matter. Essential responsibilities still need clear owners. When implementation, security, support, or sales fall through the gaps, the founder carries the obligation and the customer experiences the failure.

Small AI-enabled teams therefore need concentrated senior judgment. Large organizations distribute knowledge across teams, policies, and people who have seen similar failures before. A startup has little institutional memory and little room for recovery. When a small group performs work that once required a much larger team, fewer colleagues are available to challenge consequential decisions before they reach customers.

The financial plan must reflect that reality. Founders need enough runway to learn before revenue becomes predictable and enough flexibility to respond when their first assumptions fail. They have to budget for infrastructure as usage grows, security and compliance demands, customer support, and sales cycles that move at the customer’s pace rather than the startup’s. Reduced engineering expense can extend runway. The company still needs enough time and capital to learn.

Go-to-market work should begin while the product is still being shaped. Customer conversations reveal language that belongs in both the interface and the sales message. Early demonstrations show which benefits buyers understand immediately and which require too much explanation. Pricing discussions reveal whether the problem is economically meaningful. Pilot projects expose implementation barriers that no feature roadmap will predict.

The relationship runs in both directions. The product determines what the company can sell, while sales reveals what the company should build. A repeated objection may identify a missing capability, but it may also expose weak positioning, an unclear buyer, or a market whose economics do not fit the product. Treating every objection as a feature request allows activity to replace diagnosis.

Paying customers create a kind of evidence that compliments cannot. A small number of customers who renew, expand their use, and recommend the product can establish more credibility than a large audience that expresses interest without committing. The first durable success is a repeatable exchange: customers receive enough value to keep paying, and the company receives enough revenue to keep serving them. A viral launch may attract attention; renewal proves the relationship works.

Someone still has to create and sustain that exchange by running the meeting, understanding objections, negotiating the agreement, and supporting implementation. AI can prepare research, summarize calls, and automate parts of the workflow, but the commercial relationship depends on a company being willing and able to stand behind what it sells.

The coming years will produce more successful one-person and very small software companies. They will succeed because unusually capable people learn which responsibilities to automate, outsource, postpone, and own themselves. Their organizational charts may look unlike those of conventional startups, but the underlying responsibilities remain.

Once customers begin using the product, another test starts. The company must decide whether it can learn from what the market is telling it or whether faster execution will simply reinforce the choices it has already made.

The Speed Trap

The strongest companies do more than build products; they develop a way of becoming less wrong. That process begins with the evidence gathered before development, but it continues after launch. Customer conversations, failed sales, support requests, usage patterns, and incidents all contain information about the distance between what a company believes and what is actually happening. Every organization receives these signals. The difference is whether it can interpret them without protecting the decisions that produced them.

A support ticket may look isolated until similar complaints reveal a design assumption customers do not share. A lost deal may appear to be a pricing problem until buyers repeatedly cite implementation risk. Low adoption may seem to require better promotion when users simply do not value the feature. These signals become harder to interpret as investment accumulates. The more software a team has built around an assumption, the harder it is to question it. AI can intensify the attachment by producing abundant evidence of activity before there is evidence of value. A strategic mistake starts to feel like momentum.

Strong product organizations treat software as part of a learning loop. They form a hypothesis, build a credible test, observe what people do, and revise their understanding. AI can shorten that loop by accelerating prototypes, analysis, and delivery. The advantage disappears when speed is used to avoid the question: building ten features instead of testing one assumption, revising the landing page instead of investigating why users leave, or searching for a new market before understanding what failed in the first one.

Speed has long been a business advantage, and AI extends it by reducing the time between a decision and its implementation. Direction still comes from the organization. A company can add customers to an unstable system, expand a product whose economics do not work, or automate a process that should have been redesigned. Because each additional choice appears inexpensive, another feature, integration, or market seems easy to justify until the product loses its center.

The needed discipline is selective restraint: the ability to pause at decisions that should not be delegated to momentum, including the definition of the customer, the security model, the economic assumptions, the architectural boundaries, and the promises written into a contract.

There are two kinds of speed. Mechanical speed measures how quickly a company turns a decision into software. Cognitive speed measures how quickly it recognizes that the decision was wrong. They often diverge. A team can ship every week, collect extensive analytics, and still avoid the conversations that would challenge its interpretation. Cognitive speed requires honest feedback, authority to change course, and teams that can stop building without treating the decision as defeat. The fastest company may be the one that spends the least time building the wrong software.

That is a more useful standard for evaluating AI inside a business. Does the company reach better decisions sooner, reduce rework, improve customer outcomes, and become more capable of correcting itself? If output rises while disorder downstream consumes the gain, the company has automated activity. If a small team can test assumptions quickly, operate a reliable system, and remain close to customers, AI has improved its capacity to learn.

Technological shifts are often described by what they make possible, but their deeper effect is what they make ordinary. The internet made publishing and distribution widely available, increasing the value of attention and trust. Cloud computing made infrastructure available on demand, increasing the value of architecture and operational discipline. As capable models and coding tools become common, access to them becomes a baseline rather than a differentiator. Features will be easier to reproduce, and implementation speed will become an expectation.

The companies that endure will use AI extensively. Their advantage will come from what remains difficult to copy: finding a problem worth solving, understanding the people affected by it, making sound trade-offs, earning trust, and learning faster than the market changes. AI has lowered the cost of expressing an idea in code, which makes the cost of choosing the wrong idea harder to ignore.

Technology rarely makes value disappear. More often, it transfers it. In an age of abundant execution, the scarce work is judgment.

Sources

1. Y Combinator, “Startup School Week 1 Recap: How to Evaluate Startup Ideas and How to Talk to Users” (opens in a new tab) (2019). The material emphasizes questions about customers’ actual behavior and prior attempts to solve a problem rather than hypothetical interest.
2. Anthropic, “When AI builds itself” (opens in a new tab) (2026). As of May 2026, Anthropic reported that Claude authored more than 80 percent of the code merged into its codebase and that the typical engineer merged eight times as much code per day in the second quarter of 2026 as in 2024. The account also describes engineers’ continuing responsibility for directing and reviewing the work.
3. Google DORA, “State of AI-assisted Software Development 2025” (opens in a new tab) (2025). The report describes AI as an amplifier of an organization’s existing strengths and weaknesses.
4. Stack Overflow, “2025 Developer Survey: AI” (opens in a new tab) (2025). The survey found that more developers distrusted the accuracy of AI tools than trusted it and that 66 percent cited solutions that were almost right as a leading frustration.