Every enterprise software founder is hearing some version of the same question in 2026: “Can’t we just build this ourselves?”
It is a fair question. A few years ago, building an internal tool meant a product manager, a designer, several engineers, a roadmap, infrastructure, QA, security review and months of work. Today, a small technical team with Cursor, Claude Code, Codex, Lovable, Replit, Supabase and a weekend can produce something that looks surprisingly close to a commercial SaaS product. The demo gap has collapsed.
That is changing the psychology of software buying. For a buyer, the default question used to be “which vendor should we buy?” Now it is increasingly “why should we buy at all?” But this does not mean SaaS is dead. It means weak SaaS is exposed. The AI era forces founders to answer a deeper question: what are you really selling? Are you selling a feature that an internal team can recreate with an AI coding assistant, or are you selling a workflow, an operating model, domain intelligence, implementation muscle, governance, maintenance and compounding learning over time?
That distinction will determine which startups survive the new build vs. buy conversation.
The new build vs. buy question
The classic build vs. buy framework was relatively simple. Build when the capability was core, differentiated or strategically sensitive. Buy when speed, cost, vendor expertise or standardization mattered more. AI breaks that clean separation.
A company can buy a foundation model, use an orchestration layer, connect it to internal data, build custom agents, deploy them into a proprietary workflow, monitor them with third-party tooling and train employees to operate them. Is that build or buy? Increasingly, it is both. The right question is no longer “should we build or buy?” It is “which layers should we own, and which layers should we rent?”
Most companies should not build their own foundation models. They probably should not build their own model hosting layer, vector database, speech API, OCR engine, generic agent framework or evaluation tooling. These layers are either too capital intensive, too fast-moving or too commoditized. But companies do need to own what makes their business different: proprietary data, operational context, decision rules, customer relationships, escalation paths, quality thresholds, regulatory judgment and the institutional knowledge that lives in the heads of their best employees.
That is where the new software opportunity sits. The vendor that wins is not necessarily the one that says “don’t build.” It is the one that helps the customer decide what is worth owning and what is better outsourced.
The prototype is cheap. The system is not.
AI has made the first version dramatically cheaper. It has not removed the cost of maintenance, reliability, security, workflow integration, data quality, permissions, auditability, model changes, user adoption and organizational accountability.
This is where many internal AI builds fail. The business sees a magical demo, approves a pilot, gets early enthusiasm and then discovers that the real work starts after launch. Who owns the system when the model changes? Who updates the prompts? Who maintains integrations when Salesforce, NetSuite, SAP or an internal database changes? Who handles edge cases? Who is responsible when the system gives a confident but wrong answer? Who retrains new users? Who makes sure the system improves from feedback rather than decays into another brittle internal tool?
In the AI era, building is easier, but owning is harder.
One Remagine Ventures portfolio founder building enterprise tools put it to me bluntly: “Companies can try to do what we do, allocate 30 engineers and take a few months to try to crack it. Or they can spend $100,000 to $200,000 a year with us and get all the bells and whistles and new features shipped weekly.”
That is the new sales argument. Not “you cannot build this.” They can build something. The argument is “do you really want to own the full lifecycle of this problem?” For many customers, the honest answer will be no.
The token bill is coming due
There is another reason the build vs. buy conversation is changing: AI costs are becoming visible. In the early phase of the AI adoption wave, many companies encouraged employees to use as much AI as possible. More prompts meant more experimentation. More tokens meant more learning. “Tokenmaxxing” became a kind of productivity theatre.
Now the bill is arriving.
Companies that were pushing employees to maximize AI usage are starting to ask them to minimize waste. The New York Times recently covered tech workers moving from maxing out AI use to trying to reduce token consumption. The Economist has written about companies scrambling to curtail soaring AI costs as agentic workflows drive up usage. ComputerWeekly’s interview with GitLab CIO Manu Narayan captured the shift well: GitLab is deliberately avoiding tokenmaxxing because it can drive the wrong behaviour. The goal is not more context in and more context out. The goal is business impact.
This matters for founders because the perceived cost of “we’ll just build it ourselves” is changing. A prototype built by an internal team may look cheap when measured in engineering time. It looks less cheap when you include model usage, retries, context windows, evaluation runs, monitoring, security reviews, data cleanup, tool subscriptions, staff training, failed experiments and the management time required to keep the thing alive.
AI did not make software free. It changed the cost structure. Some costs moved from headcount to inference. Some moved from upfront development to ongoing usage. Some moved from vendors to internal coordination. Some are still hidden until the pilot becomes production.
For buyers, the question is not simply “can our team build this?” It is “can we run this safely, cheaply and reliably at scale?” For founders, this is where the opportunity lies. A credible vendor can turn unpredictable experimentation cost into a predictable operating cost.
Jevons paradox for software
There is a useful economic concept here: Jevons paradox. In the 19th century, William Stanley Jevons observed that as steam engines became more efficient, coal consumption did not fall. It rose, because cheaper energy expanded the number of economically viable uses for coal.
The same may happen with software and AI. If AI makes software cheaper to create, we should not assume the world will need less software. We may need much more of it. Tasks that never justified a custom application before will suddenly become software-addressable. Workflows that were too small, too local, too weird or too manual for a traditional SaaS company can now support a purpose-built AI system.
This is particularly important for the traditional economy. The next wave of software may not look like another horizontal SaaS platform sold to every enterprise. It may look like thousands of vertical and workflow-specific products that make previously uneconomic software categories viable. AI does not just lower the cost of building. It expands the surface area of what is worth building.
That is Jevons paradox for enterprise software.
The ICP is moving into the traditional economy
AI changes the ICP for many software companies. Historically, the best early customers for new software were often tech-forward enterprises, high-growth startups or innovation teams inside large companies. These buyers had budget, urgency and a willingness to experiment. They also had one drawback: they were often capable of building internally.
In the AI era, the most attractive ICP may shift away from the obvious technology buyer and toward the traditional economy: manufacturers, logistics providers, construction companies, industrial distributors, healthcare operators, insurance companies, finance teams, legal operations and mid-market businesses with messy but valuable workflows.
These companies have large pools of work that were never properly digitized. They still run on PDFs, spreadsheets, emails, phone calls, legacy systems, tribal knowledge and “ask Sarah, she knows how it works.” They have real operational pain, but historically the software market did not serve them well because the workflows were too bespoke and the implementation effort was too high.
AI changes the economics. A mid-market manufacturer may not need a generic AI assistant. It may need an agent that helps sales engineers turn messy customer requirements into a quote. It may need a system that reads supplier emails and updates procurement workflows. It may need AI to triage warranty claims, generate compliance documentation, analyze machine downtime, recommend spare parts or help a plant manager understand why throughput dropped on line three last week.
These are not glamorous workflows, but they are where a lot of the economy actually operates. The best customers may not be the ones asking for “AI transformation.” They may be the ones saying: “We are drowning in manual work, our best people are bottlenecks and our current software does not understand how our business really runs.”
The new startup risk: becoming a one-off artifact
Not every AI product deserves to exist as a company. If the product produces a one-off artifact, it is vulnerable. A report, a summary, a simple dashboard, a generated email, a deck, a workflow script or a chatbot over a small knowledge base can be useful, but these are increasingly easy to reproduce.
The more your product looks like a prompt, the more likely it is to be replaced by a prompt.
Durable AI companies will need to create continuous value. They will need to learn from usage, accumulate workflow-specific context, improve decisions over time and embed into processes that matter. A good test for founders is this: if a customer used your product for six months and then cancelled, would they lose something that had compounded inside your system?
If the answer is no, you may not have a product moat. You may have a feature.
How founders should qualify build risk
Founders should qualify prospects differently now. It is not enough to ask whether the customer has pain and budget. You need to understand their internal build capacity, their maintenance appetite and their cost discipline around AI.
The first question is who inside the company believes they can build this. If the answer is a strong internal AI team with budget and executive support, your sale will be harder. If the answer is “our CTO said maybe someone could hack it together,” your real competition may be inertia, not internal build.
The second question is who will own the system after the prototype. Many internal builds die because ownership is unclear. A demo can be everyone’s favourite project, but a production system needs an owner, a budget, a security model and a roadmap.
The third question is how costly it is to be wrong. The higher the cost of errors, the more buyers should value monitoring, governance, audit trails, human review and accountability. This is especially true in regulated industries or workflows touching money, safety, compliance, customer commitments or sensitive data.
The fourth question is how messy the workflow is. Messiness is bad for generic tools but good for startups that can productize domain expertise. If the workflow is full of exceptions, tacit knowledge, edge cases and handoffs, there may be a valuable company hiding inside the complexity.
The fifth question is whether the product improves with repeated use. If the system gets better as it observes decisions, corrections, exceptions and outcomes, you have the foundation for compounding value. If it resets to zero every time the user opens a new chat, the value is easier to copy.
The sixth question is whether there is a measurable business outcome. “Productivity” is too vague. Reduced quote turnaround time, fewer rejected claims, lower downtime, faster collections, shorter onboarding, fewer support escalations and better conversion are easier to buy.
The seventh question is whether the customer understands the real cost of building. Engineering hours are only one line item. Token usage, evaluation, monitoring, security, maintenance, reliability, data quality and change management all belong in the calculation.
The best ICP is not simply “companies that cannot build.” It is companies where building is tempting but incomplete. They can create a prototype, but they lack the domain depth, maintenance capacity, workflow integration, governance and feedback loops to make it valuable in production.
What founders should sell instead
The old SaaS sales motion sold seats, features, dashboards and efficiency. The AI-native sales motion needs to sell something closer to operational leverage.
That means founders should emphasize workflow ownership, not just task completion. They should sell domain-specific judgment, not generic intelligence. They should integrate into existing systems, not create another destination app. They should speak about time to value, not model sophistication. They should make governance and quality control part of the product, not a security appendix at the end of the sales process. They should show continuous learning, not static output. Most importantly, they should sell business outcomes, not “AI transformation.”
This is especially true in traditional industries. A manufacturer does not care that your product uses the latest model. They care that orders are processed faster, fewer mistakes reach the factory floor, downtime is reduced and their best people are no longer stuck answering repetitive questions.
The founder’s job is to make AI boring enough to be trusted and useful enough to become indispensable.
Why traditional industries may produce the next wave
A lot of AI innovation so far has been concentrated in obvious knowledge-work categories: coding, content creation, sales, customer support, research, design, legal drafting and analytics. These are large markets, but they are also crowded. Many buyers already have internal champions experimenting with tools.
The underappreciated opportunity may sit in the less glamorous parts of the economy: industrial operations, field services, logistics, food production, compliance-heavy back offices, insurance operations, procurement and the long tail of mid-market companies that never had software built precisely for them.
These industries have attractive characteristics for founders. Pain is measurable. Workflows are repetitive but not simple. Data is proprietary but underused. Labor shortages are real. Existing software is often old and fragmented. Internal AI teams are usually limited. ROI can be tied to revenue, cost, risk or speed.
This is not a call to build “AI for manufacturing” as a generic category. The winning companies will likely start much narrower: AI for quoting custom metal parts, AI for warranty analysis in heavy equipment, AI for procurement exception handling, AI for construction submittals, AI for compliance documentation in food manufacturing or AI for collections in B2B distribution.
The narrower the wedge, the easier it is to understand the workflow better than both the customer’s internal team and the horizontal AI platforms.
What this means for venture
For investors, the build vs. buy debate changes diligence. It is no longer enough to ask whether the company uses AI or whether the product is technically impressive. We need to ask whether the startup is solving a problem that survives the customer’s internal build instinct.
The best AI companies will likely share a few traits. They will be close to the workflow. They will have a painful, specific ICP. They will own feedback loops that improve the product. They will integrate into systems of record. They will sell measurable outcomes. They will understand the buyer’s operational constraints. They will turn unpredictable experimentation into a reliable operating system.
The companies most at risk will be horizontal wrappers that produce generic artifacts without accumulating context or ownership. They may grow fast on curiosity, but churn when customers realize they can recreate 80 percent of the value themselves.
In the AI era, “can they build it?” is the wrong question. Of course they can build something. The better question is: can they keep it working, make it better, control the costs and turn it into an operational advantage?
That is where founders should build. And that is where customers should buy.
He is a former General Partner at Google Ventures (GV) in Europe, former head of Google for Entrepreneurs in Europe, and founding head of Campus London, Google's first startup hub. Eze writes on Israeli tech, venture capital, artificial intelligence, and founder strategy.
He is also the founder of Techbikers, a nonprofit that brings together the startup ecosystem on cycling challenges in support of Room to Read.
- Cheap Prototype, Expensive Maintenance - June 25, 2026
- The Venture Capital Paradox: Why This Market Is So Hard to Read - June 24, 2026
- Geopolitics Fuels Israel’s $12bn Defense Tech Surge - June 22, 2026
