Artificial intelligence is changing the rules by which companies are conceived, built, distributed, priced and scaled.

The central message from the discussion is the unit of value is moving from software to outcomes. While simple it may look but make no mistake – it’s layered! 

For years, entrepreneurs built applications, tools and platforms and then persuaded customers to adopt them. In the AI era, that sequence is increasingly reversed. The starting point has shifted from, “What kind of software can I sell?” to “What business outcome can I own?” While the technology is becoming dramatically easier to assemble, the harder and more valuable work is understanding the customer’s problem deeply enough to deliver the result.

This has implications not only for startups, but also for established software companies, services businesses and enterprises saddled with legacy tech.

First, choose the game you are playing

There are fundamentally two ways to build a company: bootstrap it using customer money, or build a venture-backed business using external capital. These are not interchangeable models because the rules, expectations and success definitions, are largely different.

The discussion emphasized that founders frequently make the mistake of trying to play one game with the rules of another. A bootstrap business can build a highly profitable and durable company without chasing venture-scale growth. The speaker cited two companies in which he had participated that were bootstrapped, which subsequently sold for more than $200 million, and created substantial value to their teams.

Venture capital, however, demands a different trajectory. The business must have the potential for rapid distribution, market leadership and in turn, achieve significant scale. While a conventional SaaS product can still make money, but that does not automatically make it venture capital-backable. In an environment where AI can replicate large amounts of software functionality rapidly, the question becomes, why will this company become disproportionately large?

That distinction should be made early, because the answer determines almost everything that follows—product design, pricing, distribution, organizational structure and even the category-type of customer a founder should pursue.

Then, choose the market before you choose the product

AI does not create equal opportunity across industries. A recurring theme in the discussion was that the most attractive markets are often legacy, physical-world businesses—insurance, healthcare, trucking, supply chain and manufacturing—where operations remain fragmented, internal AI capabilities are limited and incumbent organizations cannot change overnight. This creates an unusual structural advantage for startups. By contrast, digitally native businesses that already have strong engineering and product organizations can often build similar capabilities themselves.

The strategic implication is that founders should not only ask where AI can be applied but also, exactly where AI creates a structural advantage – because the incumbent cannot respond at the same speed. The opportunity is particularly compelling when the underlying industry is profitable but operationally inefficient.

Stop selling software and start owning outcomes

The most important shift is the move from product-centric to outcome-centric thinking.

Product entrepreneurs traditionally describe their product in terms of features: software, widgets, tools, dashboards or workflows. Distinctly different, the AI-native founder asks, what result does the customer actually want?

The sharper the outcome, the easier the value proposition becomes. If explaining the outcome requires several minutes of product education, it is probably still too abstract. The objective is to keep moving down the stack so the customer can understand what is being delivered and why it matters.

Consider the example of Zenote, which historically provided software for salons, spas and related businesses covering scheduling, inventory, HR, collections and payments. The company began reframing its proposition around a very specific outcome which is, eliminating or significantly reducing front-desk work.

Instead of selling “front-desk software,” the proposition became, we will run your front office.

The economics now made more sense. A front-desk employee may represent a significant annual cost, while an AI system can potentially automate calls, scheduling and other routine interactions at a fraction of that cost. Zenote started narrowly—automating calls during periods when staff were unavailable—demonstrating measurable improvement and then expanding the scope. As automation performed routine activity, the human employee(s) could transition toward a higher-value “experience manager” role, focused on customer relationships rather than answering phones.

The same principle appears in healthcare. The proposition is not “medical-record management.” The more important question is, what does it cost the hospital today to process a record, and can that entire outcome be delivered at dramatically lower cost?

This changes pricing as well.

Outcome-based pricing can be much easier for a business buyer to understand than per-seat software pricing. In customer support, for example, the proposition can move from paying for software seats to paying for successful calls or completed interactions. The product may still be software underneath, but the vendor is taking responsibility for the outcome.

Three levels of interception

The discussion also offered a useful way to think about outcome ownership. There are three increasingly ambitious levels of interception: become the outcome provider yourself; take over an existing player’s operation and deliver it more efficiently; or automate a specific workflow within that operation.

The distinction matters because the deeper the interception, the more responsibility—and potentially the more economic value—the AI company can own. A workflow automation product may save a customer time, while an AI-native operator can potentially own the entire business result. The sharper and more measurable the outcome, the easier it becomes to demonstrate value and justify outcome-based pricing.

AI creates two kinds of opportunity

The market is producing two distinct waves of AI adoption.

The first is the recognizable use case, which is about doing something that humans already do, but faster, cheaper or better. Coding, documentation, testing and customer support are obvious examples. Tasks that historically required human effort – and a huge lot of it – can increasingly be performed by agents.

The second—and potentially much larger—opportunity is the net-new use case: things that were economically or operationally impossible before AI reduced the cost of execution.

One example discussed was a service aimed at consumers who struggle to understand complicated banking or credit communications. An AI system can interpret a bank’s communication, generate an appropriate response and help the customer address the issue for a very low monthly price. The important insight is not the technology itself but that AI has made a previously uneconomic problem addressable at mass-market scale.

The same dynamic is visible in generative content, voice and “vibe coding.” New categories are emerging because the cost of production has collapsed. When creation becomes dramatically cheaper, entirely new business models become possible. The opportunity is therefore not only to automate existing work, but to identify activities that were never economically viable and make them viable for the first time.

That is why companies with fewer than 15 people can sometimes move extraordinarily quickly. They are not merely building a smaller version of an existing company, but addressing a newly accessible problem.

The new moat is not code

Perhaps the most profound implication of AI is the declining strategic value of code itself.

The old technology moat was often expressed in lines of proprietary code: “We have millions of lines of software – therefore competitors cannot catch us.”

That logic is weakening.

The discussants gave an example of a system capable of using hundreds of agents in parallel to reproduce complex software functionality from specifications and use cases. The insight was not that every product can instantly be rebuilt, but that the marginal cost of generating sophisticated software is collapsing. High-quality engineers can increasingly produce vastly more code and functionality than what was possible earlier.

This changes what technical differentiation means.

There can still be deep moats in fundamental algorithms, infrastructure primitives, models and specialized systems. The example of Turbopuffer illustrates this: its differentiation is rooted not simply in adding features, but in deeply redesigning indexing, storage and retrieval primitives. The strategic question is not “Can I build this?” but “What is the deepest primitive in this system that I can fundamentally redesign?”

For everyone else, code becomes disposable.

AI-native companies must be willing to throw away three months of engineering work if a new model or tool can achieve the same result better. There should be no emotional attachment to code. The objective is the outcome, not preservation of the implementation. Continuous evaluation becomes essential because the underlying models, reasoning engines, context-management techniques and harness layers are moving too quickly for static architecture to remain valuable for long.

The real moat is moving from code to context

If code is becoming abundant, context becomes scarce.

Context includes the accumulated knowledge of how a company actually works: its processes, exceptions, workflows, decisions, tribal knowledge, customer interactions, legacy systems and organizational memory.

This is precisely what conventional enterprise software struggles to capture.

A CRM may record the formal five-step sales process, but a real sales conversation can contain hundreds of subtle signals such as, what the buyer implied, what changed, which objection mattered, what timing signal emerged and what the salesperson should do next. That “dark knowledge” normally disappears.

The emerging opportunity is to capture that context continuously, structure it and make it actionable for AI agents.

The engine of differentiation is transitioning from code to context. Context comes from legacy software, conversations, human inputs and workflows, and its value increases dramatically when it crosses organizational boundaries.

The restaurant supply chain is a useful illustration. A restaurant’s ordering decision may depend on refrigerator inventory, expected customers, conferences, menu changes, supplier availability, distributor relationships and payment arrangements. No single system necessarily contains the complete picture. AI can potentially automate the end-to-end process, but only if it understands that distributed context.

That is where many of the most interesting AI opportunities lie: not in replacing one screen, but in connecting previously disconnected fragments of knowledge and workflow.

Build the harness, but invest in evals

The discussion distinguished between the model layer and the harness layer—the software and orchestration between the underlying model and the business outcome. The harness can be strategically important, but it is also vulnerable to rapid model improvement. A better model can suddenly make months of engineering redundant.

The durable investment, therefore, is the evaluation loop. Strong evals continuously test whether the system is still delivering the intended outcome as models, prompts, reasoning approaches and tools change. Harvey provided a striking illustration: after investing heavily in its own legal model, it was willing to discard that work when a newer model could achieve the required result more effectively. The insight is, do not protect the implementation; protect the outcome and the ability to measure it.

The winning architecture: zero replacement

For enterprises, the biggest barrier to AI adoption is often not technology, but disruption.

Large organizations have years of custom workflows, integrations, rules, data structures and employee practices. Telling them to replace the underlying system before adopting AI creates enormous friction.

The more compelling proposition is the opposite, i.e., zero replacement.

AI should behave like water filling a bottle full of rocks. It should enter the existing environment, work with APIs where APIs exist, work through interfaces where APIs do not exist, accommodate home-grown systems and produce the promised outcome without forcing the customer to rebuild its technology estate.

This is particularly powerful for Indian technology companies because it combines two strengths: deep understanding of messy enterprise environments and access to sophisticated AI engineering.

The opportunity is to become simultaneously a technology company and a services company with product-grade engineering on one side and hands-on last-mile execution on the other.

Land with a wedge, then expand

In the new environment, the ideal enterprise entry point is not a grand transformation program. It is a narrow, painful and measurable problem.

The prescription is straightforward: land with the narrowest provable outcome and expand from there.

The first 10 customers matter disproportionately. Design partners help shape the proposition, establish trust and provide the evidence needed to sell the next customer. A small pilot should have explicit success criteria and, ideally, a defined path to conversion if those criteria are met.

The same principle works inside large companies. A single engineer or salesperson can become the entry point. Product-led growth does not disappear in enterprise markets, it simply starts at the individual level and expands organizationally.

Security creates a second constraint. Approaching a large company through the corporate procurement process can mean triggering security reviews, compliance requirements and the CISO’s frown, before value has been demonstrated. Bottom-up adoption can provide a more effective path where a user adopts the product, experiences value and brings colleagues into the workflow.

The most elegant enterprise entry strategies therefore solve an obvious problem using information that does not initially require sensitive data. One example involved helping CFO teams research and prepare SEC-related material using publicly available information. Once trust was established, the relationship could expand toward more sensitive workflows.

Distribution velocity is a strategic advantage

Product quality alone is no longer sufficient. The session placed unusual emphasis on distribution velocity: in fast-moving AI markets, category leadership can become self-reinforcing, with the leading few companies capturing a disproportionate share of the market. Founders therefore need to design distribution as deliberately as they design the product.

The appropriate model also changes with deal size. For smaller deals, pure product-led growth can allow an individual user to adopt the product without organizational friction. As deal sizes increase, field-deployed engineers can bridge the gap between product and customer operations; at still larger contract values, physical presence becomes increasingly important. The common pattern is land-and-expand: enter through the narrowest provable outcome, demonstrate value quickly, and expand from inside the customer.

AI-native services: Product economics with last-mile execution

One of the most overlooked opportunities is the convergence of software and services.

Traditional software assumes customers will adapt their workflows to the product. Traditional services assume people will perform the work manually. AI creates a third model: automate the service outcome while using human expertise where necessary.

This can begin with a highly customized engagement. The critical objective is then to standardize the recurring elements.

Rapid Canvas was discussed as an illustration. It initially delivered highly customized solutions, but over time built enough reusable capability that the business reportedly reached a model where roughly 70–80% became platformized, and only 20–30% remained customer-specific. The strategic objective is not to eliminate customization on day one, but to turn repeated customization into reusable product capability.

That is the critical transformation: custom work is not necessarily the failure of repeatability. Done correctly, custom work becomes the raw material from which repeatability is extracted.

This creates a potentially powerful category of AI-first service companies—businesses that combine the engineering intensity of a Valley software company with the last-mile execution capability traditionally associated with large services firms. The opportunity exists precisely because the real world contains broken data, fragmented integrations and inconsistent processes that pure software products often cannot handle.

And repeatability becomes a critical operating metric: how quickly can the same use case go live with the next customer, and how is the platform-to-custom ratio improving over time?

The new founder is full-stack

The organizational implications are just as significant.

The successful founder of the AI era increasingly needs to understand technology, product, positioning, marketing and sales simultaneously. AI has lowered the cost of building, which shifts the bottleneck toward judgment: deciding what should be built, for whom, and why it matters.

This is one reason very small teams can now produce disproportionately large outcomes. The distinction between “technical founder” and “business founder” is becoming less useful. The emerging archetype is the full-stack founder—someone capable of building, selling, marketing and positioning the product.

The same transformation is creating a new enterprise role: the forward-deployed engineer or FDE.

The old model was a sales engineer who demonstrated software. The new FDE understands the customer’s business, enters the environment, identifies what should be automated, works closely with engineering and product, and rapidly iterates the solution with the customer. Their core responsibility is discovering and encoding organizational context.

The Field Deployment Engineer, or FDE, is central to this model. The FDE combines business understanding, technical ability and customer-facing skills, working inside the client’s environment while feeding learning back into the product. This creates a potentially powerful economic model for Indian technology companies: sophisticated product engineering combined with lower-cost, high-quality last-mile execution. The session suggested an entry point of roughly $75,000–$100,000 for this type of engagement—large enough to represent meaningful customer value, but below the level at which traditional large services firms are typically interested.

This role matters because enterprise autonomy cannot be achieved without understanding the organization’s actual operating model.

Legacy modernization becomes an AI opportunity

A further opportunity discussed in the session is the modernization of legacy software itself. Many enterprise codebases are 10–15 years old, contain large amounts of unused or poorly understood code, and remain difficult to change because customers depend on them. The suggested migration path is pragmatic: start by making the code AI-ready rather than attempting a wholesale replacement of the data estate, progressively re-engineer existing functionality, and measure how much of the development process can be accelerated with AI.

COBOL illustrates the scale of the challenge. General-purpose models have limited exposure to some legacy languages, creating a need for context-engineering layers that can understand and operate against those codebases. The session cited a tree-sitter-based approach being used to support an ongoing COBOL modernization agent for the Johannesburg Stock Exchange.

For Indian technology companies, the strategic prize is substantial. The discussion framed the modernization opportunity against the roughly $500 billion Indian IT export industry: a vast installed base of enterprise software that ultimately needs to be modernized. AI-native teams could attack this market with a fundamentally different cost and velocity model

The strategic imperative: leadership takeaway

The AI transition ultimately demands a different operating philosophy.

• Build for outcomes, not features.
• Choose the right capital model.
• Start with narrow, high-value wedges.
• Treat distribution velocity as a strategic asset.
• Use design partners to learn before scaling.
• Expect code to become increasingly disposable.
• Build evaluation loops strong enough to survive model changes.
• Capture context continuously.
• Enter legacy environments without demanding replacement.
• Combine product economics with last-mile execution.
• And above all, understand the difference between building something and owning an outcome.

The greatest AI companies may not look like traditional software companies. Some will build entirely new products. Some will reinvent legacy industries. Some will become AI-native services companies. Some will create infrastructure primitives so deep that they become foundational. Others will quietly transform how existing enterprises operate.

The common thread is not the model they use or the amount of code they write.

It is the ability to identify a valuable outcome, deliver it dramatically better, and build the distribution and context advantages that allow that capability to compound.

The technology is changing extraordinarily fast. That means the window for technical differentiation based purely on implementation is narrowing.

But it also means the opportunity is expanding.

In the AI economy, code is becoming abundant. Context, outcomes, trust and distribution are becoming scarce. The companies that understand that shift earliest will have the strongest chance of defining the next generation of markets.