Kastle won banking customers by offering a mortgage servicer that was AI-native from the start, beating incumbents whose AI additions were traditional software with new marketing layered on.

Two startups, winning in regulated financial workflows against far larger incumbents. The pattern: the incumbents didn’t fall behind because the technology was immature. They fell behind because they never solved the production problem.

The 95% number is real, and it’s worse than it sounds

MIT’s NANDA report found that 95% of enterprise generative AI pilots fail to deliver a measurable return. Not a small return. No return that shows up in the business at all.

The pipeline is more brutal than the headline suggests. 60% of organisations evaluate AI tools. 20% reach the pilot stage. Only 5% make it to a live production environment. The attrition is compounding.

The gap between “we have a working pilot” and “this runs in production” is where the money disappears. RAND Corporation found that more than 80% of AI projects fail, twice the failure rate of traditional IT projects.

Five gaps that explain most of the failures

The failure patterns are consistent across every study and every industry. Five problems surface in nearly every post-mortem:

Integration complexity. Enterprise systems don’t come with clean APIs. They come with legacy ERP configurations, undocumented integrations, and middleware that nobody fully understands. The pilot works in isolation. It breaks the moment it touches the production stack.

Output quality at volume. AI performs well on the test set. It degrades on edge cases that weren’t visible in a limited pilot. A medical coding agent that handles 80% of claims accurately is impressive in a demo. In production, the 20% it mishandles creates regulatory exposure and financial loss.

Monitoring and observability. Most pilots have no production-grade tracking for quality drift or task completion. The agent starts hallucinating on a Wednesday night and nobody notices until Friday morning when the reports are wrong.

Organisational ownership. Who owns the AI system? IT thinks it’s a business project. The business thinks it’s an IT project. Nobody has clear accountability, so nobody makes the decisions required to move from pilot to production.

Insufficient domain data. The model is capable, but it doesn’t have enough labelled examples in the specific vocabulary, formats, and exception patterns of the organisation. The gap isn’t intelligence. It’s context.

Of these five, observability is the one the frontier has converged on. It was the throughline at Arize Observe in San Francisco this June: the production problem in enterprise AI is no longer building the model, it is knowing the exact moment it starts to drift and catching it before the business does. A pilot can hide its failures. A production system cannot, which is why the teams that win the last mile instrument for it from day one instead of bolting it on after the first incident.

Why enterprises are bad at this (and startups aren’t)

There is a quieter dynamic underneath this. Enterprise engineering teams often don’t believe in AI. They view it as overhyped, and they’re quietly relieved when a pilot fails, because it validates their scepticism.

When these teams do try to build, the work is often outsourced and designed by committee, several steps removed from the production floor where the system has to run. That distance is the real problem. The people closest to the model are rarely the people closest to the workflow, so the output satisfies the brief and then breaks on contact with the actual operation. I spent years inside large enterprise programmes; the failure is structural, not a question of effort or intelligence.

Startups win because they don’t carry this baggage. They start from production requirements, not from a pilot mandate. They embed engineers with the customer, surfacing the unwritten rules that no documentation captures and no dataset contains. This is the “Forward Deployed Engineer” model, and it’s emerging as the differentiator between AI startups that close enterprise customers and ones that stay stuck in demo mode.

Reducto, a YC company, won a Fortune 10 enterprise as a customer by beating that company’s own internal engineering team, which was building the same document-processing capability with full access to its own context and data. Reducto won because it kept getting measurably better day after day, iterating against the production edge cases the internal team had been staffed on for months.

Where production works

Financial services leads on production deployment, by a wide margin. The reason: heavy investment in document processing and compliance automation, where the cost of human error is quantifiable and the ROI of automation is immediate.

Healthcare sits near the bottom. Regulatory complexity, extreme risk aversion around clinical workflows, and the resistance of professional structures that Marc Andreessen describes as “cartels” naturally opposed to technology that threatens established processes.

The gap between the sectors is not about model capability. Both have access to the same models. The difference is organisational: how much institutional resistance exists, how quantifiable the ROI is, and whether a founder can find a workflow where AI reliability is sufficient and the human stakes are manageable.

Danfoss automated 80% of transactional purchase order decisions. Response times dropped from 42 hours to near real-time. The result: millions of euros in annual savings. The key detail: they started with a narrow, well-defined process where the rules were mostly explicit and the exceptions were manageable. They didn’t try to automate judgment. They automated intelligence.

The production gap is the opportunity

The 95% failure rate is not a discouraging statistic. It’s a market signal.

Every failed enterprise pilot represents a budget that was allocated, a problem that was identified, and a solution that didn’t get built properly. The demand exists. The willingness to pay exists. What doesn’t exist is the capability to bridge the gap between what AI can do in a controlled environment and what it needs to do when institutional memory, undocumented workflows, and organisational politics are involved.

The startups that close this gap won’t do it by building better models. They’ll do it by understanding the customer’s operation at a depth that the customer’s own internal teams, working at a distance from the live workflow, could not reach. That understanding is the product. The AI is the delivery mechanism.

The last mile isn’t a technology problem. It’s a judgment problem. And judgment, unlike compute, doesn’t scale with hardware.

On February 3, 2026, $285 billion in market value vanished from enterprise software companies in a single trading session. Jefferies trader Jeffrey Favuzza coined the term that stuck: the SaaSpocalypse. By the time the selling settled, the damage had crossed $2 trillion. HubSpot was down more than 50% from its January high. Monday more than 40%. ServiceNow more than 30%. Atlassian, which had never before seen a decline in enterprise seat counts, reported its first. Then laid off 1,600 people. Then lost its CTO.

The trigger was specific. Anthropic released a set of open-source plugins for Claude Cowork, automating multi-step workflows across legal, sales, finance, and support systems without human input. Days later, OpenAI shipped Codex for Mac, which crossed a million downloads in its first week. The market did the math: if an AI agent can navigate the software, you don’t need the human sitting in front of it. If you don’t need the human, you don’t need the seat.

But here’s the part most coverage missed.

The real story isn’t AI. It’s discipline.

Marc Andreessen put it directly on 20VC: the layoffs are not about AI. They’re about COVID.

During the zero-rate era, companies went on a hiring binge with zero accountability. Employees became icons on a screen. Nobody could tell who was productive and who wasn’t. Andreessen estimates that essentially every large company is overstaffed by 25 to 75 percent.

AI is the “silver bullet excuse.” CEOs who needed to cut the bloat now have a narrative that sounds visionary instead of embarrassing. “We’re replacing SDRs with agents” plays better in a press release than “we hired too many people when money was free and now we can’t justify the headcount.”

This doesn’t mean AI doesn’t matter. It means that the per-seat model was already fragile. The seats were never all productive. AI just made it impossible to pretend otherwise.

The structural problem with per-seat pricing

The per-seat model worked when software required a human operator. One user, one login, one subscription. The economics were clean: more employees meant more seats meant more revenue.

That logic breaks when one person with AI agents does the work that previously required ten. Monday replaced 100 SDRs with agents. Response times dropped from 24 hours to 3 minutes. Conversion rates improved. Whatever you think about the PR spin, the arithmetic is real: the company that used to buy 100 seats now needs a fraction of that.

Workday cut 8.5% of its own workforce. A company that sells workforce management software, reducing its own headcount because of AI. Thomson Reuters had its largest single-day decline on record. The pattern is consistent: the companies most affected are the ones whose entire revenue model depends on seat expansion at a time when the number of seats required is contracting.

Per-seat pricing adoption dropped from 21% to 15% of the enterprise SaaS market in the twelve months leading to March 2026. That shift is accelerating.

What replaces it

Gartner projects 40% of enterprise SaaS contracts will include outcome-based elements by end of 2026, up from 15% in 2024. Bain published research concluding that per-seat pricing is “structurally vulnerable” and that vendors who fail to transition within 18 months face permanent erosion.

The replacement models look different depending on the product:

Outcome-based: You pay for results delivered, not tools used. Sierra crossed $100 million in annual recurring revenue in 21 months by selling customer service outcomes, then doubled to $200 million by May 2026. Not “a tool your support team uses.” The actual resolution of customer issues, priced per resolution. Decagon does the same, selling units of completed work rather than seats.

Usage-based: You pay for what you consume. This is already standard in infrastructure (AWS, Stripe) and is migrating up the stack into application software. AI-native companies that price this way report lower churn and stronger net revenue retention than per-seat equivalents, even as compute costs compress headline margins across the category.

Hybrid: Some vendors are keeping a base platform fee but shifting the growth component to usage or outcomes. This is the transition path for incumbents who can’t abandon their existing contract base overnight.

The common thread: the customer pays for value received, not humans employed. When the number of humans involved in a workflow drops, the vendor’s revenue doesn’t collapse. It compounds.

The pricing question becomes an architecture question

Per-seat isn’t dead for every product. Some workflows still require a human operator per seat, and will for years. But the market just repriced the model by more than two trillion dollars. That’s a signal worth reading carefully.

The interesting shift: pricing is becoming an architecture decision, not a business decision. When the product is structured so that AI makes it more valuable per user, usage-based or outcome-based pricing aligns revenue with the technology trend. Every model improvement makes the product more useful and revenue grows. With per-seat pricing, every improvement reduces the number of users needed and revenue contracts.

83% of AI-native SaaS companies already use usage-based or outcome-based pricing. The business model that powered two decades of SaaS growth is misaligned with the technology that’s defining the next two. That’s what the SaaSpocalypse actually revealed.

Except it probably isn’t what it looks like.

Marc Andreessen made the point bluntly on 20VC shortly after: companies that hired recklessly during the zero-rate COVID years are now overstaffed by 25 to 75 percent. AI is the “silver bullet excuse” to cut the bloat. If you can fire 100 SDRs and performance improves, the question isn’t how smart the agents are. It’s why you had 100 SDRs in the first place.

That’s not AI-first. It’s a mature SaaS business running a restructuring and branding it as innovation. A different thing entirely. Knowing the difference is what this piece is about.

The wrapper trap

Sixty percent of YC’s W26 batch is AI companies, up from 40% two years ago. Fourteen of them hit $1M in annual revenue by Demo Day, the fastest cohort ever.

The uncomfortable question: how many survive the next model release?

When Anthropic shipped Claude Cowork with its legal and security plugins, LegalZoom dropped nearly 20% and Cloudflare fell 8% in a single session. Not because Claude targeted them. Because it made capabilities they’d been selling as premium features available to anyone with an AI assistant. Days later, OpenAI’s GPT-5.3-Codex landed with similar capabilities, compounding the pressure.

This is what happens when your product is a layer on top of a model. The model improves. Your layer becomes a commodity. The company that built the model ships a better version of your product as a feature inside their platform.

Klarna understood this early. They replaced their enterprise CRM with an AI system they built in-house. The interesting detail: Klarna didn’t add AI to their existing workflow. They rebuilt the workflow around what AI could do natively. That’s a structural decision, not a feature decision.

Selling the work vs. selling the tool

Harvey helps lawyers draft documents faster. Crosby drafts NDAs for companies directly, no lawyer needed for routine agreements. Both use the same underlying models. Harvey sells the tool. Crosby sells the work.

When the model improves, Harvey’s users get slightly faster drafting. Crosby’s service gets cheaper and more reliable. One is racing against the model. The other is riding it.

Sequoia put numbers on this: for every dollar companies spend on software, they spend six on services. The autopilot founders, the ones delivering finished work rather than better tools, are going after a market six times larger.

But not every “autopilot” is real. Quanta raised $20 million to replace QuickBooks with AI-driven accounting. Their approach is honest: AI handles the mechanical work, humans bridge the last mile for reliability. That’s genuinely AI-first because the system can’t function without the model at its core. Compare that to a startup that bolts GPT onto a spreadsheet and calls itself “AI-powered accounting.” Same label. Completely different architecture. The second one dies when the spreadsheet platform adds the same integration.

The test is simple. Remove the AI. Does the product still exist? If yes, it’s a feature. If no, it’s a structure.

What the small team looks like

Josh Mohrer runs Wave AI. Solo founder. $7 million in annual revenue. Roughly $3 million in profit. He does all engineering and support himself using AI agents.

It’s tempting to treat this as a feel-good story about the democratisation of building. It’s more useful to ask: what is structurally different about Mohrer’s company versus a traditional SaaS startup at the same revenue?

The answer is that every function, from support to engineering to operations, runs through AI as the default path, not the exception. He doesn’t use AI to augment a team. There is no team. The AI is the operational structure. Adding a human to this system would be a regression, not an improvement, for the tasks the agents handle.

Dan Shipper’s Every runs five AI products at $1.3 million in revenue growing 45% per quarter. Their internal culture has an interesting norm: if you’re not using AI first to code, write, or design, people ask you why. That’s a cultural structure, not a feature adoption.

Giga started as a handful of engineers out of YC. They built an internal agent called Atlas that helped them close DoorDash and other large enterprise customers, beating companies many times their size. Again: the AI isn’t enhancing a traditional sales process. It replaced the need for one.

These companies aren’t succeeding because they’re using AI. They succeed because they’re structured around it. The difference sounds semantic. It’s not. It determines whether your team gets more capable as models improve, or whether it just gets slightly faster at the same tasks.

Where the gap really is

Software engineering accounts for 50% of all AI agent activity today. Healthcare, law, finance, logistics: each is still under 5%.

The models are capable. The deployment isn’t there. These industries run on undocumented workflows, institutional memory, and human judgment that has never been formalised. MIT research found that 95% of enterprise AI pilots fail to reach production, not because the technology doesn’t work, but because nobody mapped the gap between a controlled demo and the chaos of a real operation.

The 5% that succeed share a trait: they embed engineers with the customer to surface the unwritten rules that no dataset captures. They treat the distance between demo and deployment as the product challenge, not an afterthought.

This is where the press-release version of AI and the reality diverge most sharply. The headlines say “AI replaces 100 SDRs.” The reality is closer to “AI works brilliantly in a controlled environment and breaks in production because nobody accounted for the seventeen exceptions that the human team handled without thinking about it.”

Better models won’t close that gap. Better judgment will. Knowing where models work, where they don’t, and how to build the scaffolding that makes them reliable when real money and real regulations are involved.

That judgment, not the AI itself, is what makes a company AI-first.

First published on aberlay.com on May 6, 2026.

That constraint is gone.

On Lovable, 200,000 new software projects are created every day. Replit hit a $9 billion valuation by making code generation accessible to anyone who can describe what they want. FeltSense raised $5.1 million after using AI agents to clone every startup in a recent YC batch, reproducing functional versions of each in hours. Fazeshift, a small team out of YC, is beating accounts receivable incumbents with hundreds of employees.

Forty-one percent of global code is AI-generated. The number is going up. The cost of building software is approaching zero. And yet most founders are still organised around the assumption that building is the hard part.

It isn’t. Not anymore. The constraint moved. And the founders who haven’t adjusted are solving a problem that no longer exists.

Three new bottlenecks

If building is no longer the constraint, what is?

Judgment. Knowing what to build. Not in the abstract, “solve a real problem” sense that startup advice has repeated for twenty years. In the specific, structural sense: which problem, for which customer, with which architecture, at which price. When code is cheap, the ability to generate it is worthless. The ability to decide what it should do is everything.

Y Combinator’s partners observed this directly in the W26 batch: writing code is no longer the barrier. The founders who failed weren’t the ones who couldn’t build. They were the ones who built the wrong thing, or built the right thing for the wrong customer, or built something that worked in a demo but not in production.

Distribution. Greg Isenberg’s argument is uncomfortable but correct: the wealthiest builders of the next decade will be marketers, not developers. When everyone can build, the scarce resource is the ability to reach the right people. His playbook inverts the traditional startup sequence: grow an audience of 1,000 first, ask what they need, then build the solution in a weekend. This works because the cost of building dropped enough to change the order of operations.

Velocity. Not speed of coding. Speed of operationalising. Moving from a working prototype to a system that handles real customers, real money, real regulations, and real edge cases. Eighty-nine percent of enterprise AI scaling failures trace to integration complexity with legacy systems, inconsistent output quality at volume, and absent monitoring. The demo works. The production system doesn’t. Closing that gap faster than the competition is the new race.

What the new constraint looks like in practice

The “$0 to $1B” companies that Sequoia identified share a pattern. They’re not just using AI to build their product. They’re using AI to run their company. Legal, recruiting, sales, support: automated from day one, not added after scale. They hit $1 million in revenue per employee because the entire operation is structured around the assumption that AI handles the intelligence work and humans handle the judgment.

This is not an efficiency play. It’s an architectural decision. A company that hires 50 people and then tries to automate is reorganising. A company that starts with three people and AI agents is operating. The second one moves faster because it never built the organisational layers that slow the first one down.

Fazeshift captures this precisely. A small team automating accounts receivable, they document every manual task, build a custom agent for it, and delay hiring entire functions by using AI tools instead. They don’t automate what they’ve built. They build around what AI can automate.

What hasn’t changed

The constraint moved, but the hard parts didn’t disappear. They shifted.

Enterprise customers still make decisions through committees of eleven people with conflicting incentives. The political dynamics inside a Fortune 500 buyer haven’t changed because a founder can build faster. Getting the meeting, understanding the internal dynamics, earning the trust: that’s still slow, human, and relationship-dependent.

Data is still a mess. Enterprise systems are full of unstructured information, undocumented workflows, and institutional memory that lives in people’s heads, not in databases. Making that data legible to AI agents is the kind of work that can’t be vibe-coded. It requires patience, domain knowledge, and the willingness to sit with a customer’s operational chaos long enough to understand it.

Regulation didn’t get simpler. Industries like healthcare and finance have professional structures and compliance requirements that don’t bend because the technology improved. The model can handle the medical coding. It can’t handle the liability framework around getting it wrong.

And distribution. The original hard problem of startups. Code got cheaper. Attention didn’t. The founder who ships in a weekend still needs to figure out how to reach the person who will pay for what they built. That problem is, if anything, harder now because every other founder also shipped something this weekend.

The founders who adjusted

The ones getting this right made a specific shift. They stopped treating their technical ability as the competitive advantage and started treating their judgment as the product.

Ryan Carson is building an AI-native divorce service. His differentiator isn’t code. It’s feeding the system Connecticut divorce statutes and child support guidelines in structured format, then applying 25 years of operator experience to define the business logic that no model can infer. The AI drafts the communications. Carson defines what’s legally correct.

Oliver Henry built an AI marketing agent that generated 2 million TikTok views for his app. Zero downloads. The problem wasn’t content creation. It was a weak conversion funnel where users had to manually type a URL. The constraint wasn’t the AI. It was marketing judgment.

Rora hit $40,000 in revenue in its first 40 days selling AI cold-call agents. Building the initial stack was easy. The real work was supervised fine-tuning to give the model enough conversational intelligence to close a listing appointment without sounding like a robot.

The constraint was engineering. Now it’s judgment, distribution, and the gap between a prototype and a product that works when real money is involved.

Building got easier. Everything else didn’t.

First published on aberlay.com on April 29, 2026.

AI handles this now. Not as an experiment. In production, at scale, with accuracy rates that match or exceed human coders.

But deciding which treatment to recommend to the patient who generated that clinical note? That’s a different kind of work entirely. It requires weighing risks that aren’t in the manual. Reading a situation that involves the patient’s history, preferences, tolerance for uncertainty, and the clinician’s experience with similar cases.

The first task is intelligence. The second is judgment. The difference between these two determines what compounds and what gets absorbed by the next model update.

The distinction that determines your architecture

Sequoia framed it precisely: writing code is mostly intelligence. Knowing what to build next is judgment.

Intelligence work follows patterns. It translates rules, processes documents, classifies inputs, generates outputs according to templates. It requires knowledge, but the knowledge is codifiable. AI does this now, and does it better every quarter.

Judgment work requires experience. Not the kind of experience you can encode in a training set, but the kind that comes from years of watching what works, what doesn’t, and why. Deciding which feature to prioritise. Knowing when a technical architecture won’t hold at scale. Sensing that a customer’s stated problem isn’t their real problem.

The practical consequence for founders: if your product automates intelligence work, you’re building something valuable but commoditisable. The model will get better. Your advantage will shrink. If your product augments judgment, you’re building something that the model can’t replicate because the judgment itself is what makes the product different.

Iron Man suit, not Iron Man robot

Andrej Karpathy offered the most useful metaphor: build Iron Man suits, not Iron Man robots.

The robot is the flashy demo. Fully autonomous. No human in the loop. Impressive for a presentation. Fragile in production. It fails when it encounters an edge case that wasn’t in the training data, and nobody is there to catch it.

The suit is partial autonomy. The AI handles the intelligence work at machine speed. The human handles the judgment calls. The system gets faster and more capable over time, but the human remains in the critical path for decisions that require experience, taste, or accountability.

Karpathy’s practical advice: work in small, incremental chunks where verification is easy. Don’t accept a 10,000-line code dump and hope it’s correct. Keep the AI on a leash. Review its output. Catch errors before they compound. The suit makes you faster. The robot makes you reckless.

The most effective builders in this model are the ones who focus on the logic and architecture of systems rather than the language of code. A non-technical background becomes an advantage, not a limitation, because it forces you to direct the AI toward the right problems instead of getting lost in implementation details. The AI is the translator. The judgment about what to translate is yours.

Where intelligence is already a utility

The shift is further along than most people realise.

Testing and debugging: AI agents now handle unit testing, integration testing, and bug detection at a level that exceeds most junior engineers. The intelligence work of “find what’s broken and fix it” is becoming a utility.

Document review: Legal document analysis, contract comparison, regulatory compliance checking. The pattern-matching work that associates at law firms and compliance officers performed is being absorbed by models that process documents faster and miss fewer details.

Financial analysis: Earnings report summaries, market comparisons, risk assessments. The intelligence work of “read these documents and extract the relevant numbers” is automated.

Customer support: Routine inquiries, troubleshooting guides, ticket classification. The intelligence work of “understand the problem and route it to the right answer” is handled by agents.

In each case, the intelligence work became a utility. What remained valuable was the judgment: deciding what to do with the analysis, which legal strategy to pursue, which customer to prioritise, how to handle the case that doesn’t fit the pattern.

What this means for pricing

If your product handles intelligence work, your pricing is under pressure. The work gets cheaper every quarter as models improve. Per-seat pricing collapses because you need fewer humans. Your margins depend on whether the model provider charges you more or less than the value you deliver.

If your product augments judgment, your pricing is defensible. The value scales with the quality of the decisions being made, not with the volume of intelligence work being processed. Outcome-based pricing works because the outcome depends on judgment that the customer can’t get elsewhere.

The founders charging per resolution, per completed transaction, or per verified outcome are in a structurally different position from the ones charging per seat or per API call. The first group is selling judgment. The second is selling intelligence. One scales with value. The other races against cost.

Intelligence is becoming what electricity became a century ago: essential, ubiquitous, and not a basis for competitive advantage. Nobody builds a company around having access to electricity. In five years, nobody will build a company around having access to intelligence.

Judgment is the product. Everything else is infrastructure.

First published on aberlay.com on April 22, 2026.

The model generates an impressive output. The interface is clean. The founder narrates the workflow with conviction. Everyone in the room nods. The technology clearly works.

Except “works” in a demo and “works” in production are separated by a gap that most evaluators don’t know how to measure. I spent 26 years evaluating startups for technology partnerships at Fortune 500 companies. The pattern that distinguished the ones that delivered from the ones that didn’t had almost nothing to do with the quality of the demo.

Here’s what to look for instead.

Ask what happens when it’s wrong

Every AI system produces errors. The question is not “does it make mistakes?” It always does. The question is “what happens when it does?”

A mature AI startup has a clear answer: the system flags uncertain outputs, routes them to a human reviewer, logs the error, and uses it to improve. An immature one says “our accuracy is 97%” and moves on, as if the other 3% doesn’t exist.

In production, the 3% is everything. If your AI handles 10,000 transactions a day, a 3% error rate means 300 mistakes. Per day. The demo showed the 97%. Deployment is about the 3%.

Ask to see the error handling. Ask how exceptions are escalated. Ask what the system does when it encounters a case it hasn’t seen before. If the answer is vague, the product isn’t ready for production, regardless of how clean the demo looked.

Look for the data moat, not the model

Most AI startups use the same foundation models from the same handful of labs. The model is infrastructure, not a competitive advantage. Any competitor with the same API key can build a similar product.

The question is what the startup has that the model doesn’t. There are only a few real answers:

Proprietary training data. Industry-specific datasets that took years to collect and label. These are getting less defensible as models improve at reasoning through unstructured data, but they still matter in regulated industries where the data is hard to access.

Decision traces. A living record of every decision the system has made, why it made it, and what happened afterward. This compounds over time and creates switching costs that raw data doesn’t. If the startup has been running in production for a year, capturing decision context that nobody else has, that’s a moat.

Integration depth. The product is embedded in the customer’s workflow at a level that makes replacement painful. Not because of a contract. Because the system has learned the customer’s specific patterns, exceptions, and preferences.

If the startup’s advantage is “we have a better prompt” or “our UI is nicer,” that’s not a moat. It’s a head start that lasts until the next model release.

Check the revenue model against the technology trend

Per-seat pricing is under structural pressure. If the startup charges per seat and its product makes the user’s team more efficient, the customer will eventually need fewer seats. The startup’s success undermines its own revenue.

Outcome-based and usage-based pricing align with the technology trend. The product gets better, the usage increases, the revenue grows. Ask how the startup charges and whether their pricing model survives the scenario where AI gets significantly better in 12 months.

The best AI startups are already pricing per resolution, per transaction, or per completed workflow. The ones still on per-seat models either haven’t thought about this or are afraid to change because their current customers expect seat pricing. Both are risks.

Evaluate the team for judgment, not just engineering

The scarce resource in AI is no longer the ability to build. It’s the ability to decide what to build and for whom.

Look for founders with deep domain expertise in the vertical they’re targeting. A founder who spent ten years in insurance claims processing and now builds AI for that space has judgment that no amount of engineering talent can substitute.

Look for evidence that the team has spent time with customers in production, not just in pilots. The transition from pilot to production is where most AI startups die. Teams that have navigated it at least once understand the integration complexity, the edge cases, and the organisational resistance that don’t appear in the demo.

Be skeptical of teams that are “AI experts” building for a domain they don’t understand. The AI capability is available to everyone. The domain understanding is not.

Watch for the wrapper signals

Some indicators that a startup might be a wrapper rather than a structurally AI-native product:

The product could function without AI. If you remove the AI layer and the core workflow still exists, the AI is a feature, not the product. Features get commoditised.

The competitive advantage is speed, not capability. “We do what you already do, but faster” is a wrapper pitch. The question is whether the product does something that was previously impossible, not just something that was previously slower.

The team talks about the model more than the customer. A startup that leads with the model it uses is telling you their advantage is an API subscription. A startup that leads with “we reduce claims processing time by 80% for mid-market insurers” is telling you they understand the problem.

The roadmap depends on the next model release. If the startup’s plan for the next 12 months is “when the next frontier model ships, we’ll be able to do X,” their product is bounded by someone else’s timeline. The best AI startups build capability that compounds independently of which model they use underneath.

The demo is the beginning of evaluation, not the end. The impressive output on screen is the smallest part of what makes a product work. Error handling, data moat, pricing alignment, domain depth, structural independence from any single model provider: that’s what separates delivery from disappearance.

Ask what happens after the demo ends. The answer tells you everything.

First published on aberlay.com on April 15, 2026.

A teenager built a business selling AI agent setup services through a single viral post and 15-minute closing calls. No cold outreach. No CRM. No sales team.

These aren’t growth hacks. They’re evidence that the go-to-market playbook for B2B has shifted in a way that most founders haven’t absorbed.

The old sequence is inverted

The traditional startup sequence: build the product, then find customers. Spend months engineering, then spend months selling. The build phase and the sell phase are separate activities, done in order.

The new sequence: find customers, then build. Greg Isenberg’s argument is blunt. When everyone can build a product in a weekend, the scarce resource is not engineering. It’s distribution. Knowing who needs what you’re building, and having their attention before you build it.

His playbook: grow a niche audience of 1,000 to 5,000 people first. Understand their specific problems through direct conversation. Then vibe code the solution in a weekend. You launch to a warm market instead of screaming into the void.

This sounds counterintuitive if you were trained in the “build something people want” school. But the shift is logical. Building is no longer the bottleneck. The cost dropped so dramatically that the order of operations changed. Distribution is the bottleneck. And distribution built before the product exists is worth more than distribution built after.

Answer Engine Optimisation

Here’s a tactical shift that most B2B founders are ignoring: your next customer might not find you through Google. They might find you through Perplexity, ChatGPT, Claude, or Gemini.

Answer Engine Optimisation is the practice of structuring your content so that AI models cite you as the authoritative source when users ask questions in your domain. It’s different from traditional SEO. The goal isn’t to rank on a search results page. The goal is to be the answer.

The playbook is straightforward. Identify the top 20 questions your target customer asks. Write the definitive, structured, citation-worthy answer for each. Publish them ungated on your site with clear definitional openings, structured data, and no fluff.

When a founder asks Perplexity “how does prior authorisation work in medical billing?” and your article is the one that gets cited, you’ve just acquired a lead without spending a dollar on ads or making a single cold call. The founder reads your content, sees that you understand their problem at a depth nobody else does, and reaches out.

This is not theoretical. AI models now cite ungated web content within days of publication. The founders who structure their content for AI consumption, not just human consumption, are building a distribution channel that compounds without ongoing spend.

The diagnostic audit as a go-to-market

The most effective enterprise GTM strategy in 2026 is not a demo. It’s a diagnostic.

Instead of pitching your product, you offer to audit the customer’s current workflow. Two weeks. No charge. You embed yourself in their operation, document every manual step, identify where AI can handle the intelligence work, and present a report with specific recommendations.

Three things happen during this process. First, you learn the customer’s actual workflow at a level of detail that no sales call could reveal. The undocumented exceptions, the workarounds, the institutional memory that lives in people’s heads. Second, you become a trusted advisor before you become a vendor. The customer sees you as someone who understands their problem, not someone trying to sell them something. Third, you identify the exact wedge where your product fits, specific to that customer’s operation.

This approach works because it inverts the power dynamic. A demo says “let me show you what my product does.” A diagnostic says “let me show you what your operation needs.” The first is vendor behaviour. The second is partner behaviour. Enterprise buyers respond to partners.

Being found vs. selling

As of the most recent Hackett Group research, 94% of procurement teams use generative AI tools at least once a week. Forrester’s 2025 data shows buying groups average 13 internal stakeholders and 9 external participants. Decisions are increasingly finalised before a single sales call happens.

This means that if a founder’s product isn’t discoverable by AI systems, it doesn’t exist to the buying committee. The procurement team’s AI agent will scan the web, compare vendors, evaluate pricing benchmarks, and simulate negotiation scenarios. All before anyone picks up the phone.

The implication: your website, your documentation, your content, and your data need to be machine-readable, not just human-readable. Clear pricing models. Standardised specifications. Performance metrics. Compliance documentation. Integration capabilities. All visible, structured, and findable by an AI agent doing research for a procurement team.

The founders who understand this are building their entire go-to-market around being found rather than selling. They write content that gets cited by AI. They structure their product information for automated comparison. They make their pricing transparent because opacity is now a disqualifier, not a negotiation tactic.

The first customer is the hardest. It always has been. What’s changed is how that customer finds you. It’s less about outbound and more about being the answer when the right person asks the right question to the right system.

Build for that. The sales team can come later.

First published on aberlay.com on April 8, 2026.

The code is commoditised. AI generates it. The design is commoditised. AI produces interfaces that look professional. The copy is commoditised. AI writes it in any tone you specify. The features are commoditised. Whatever you ship, a competitor can replicate in days.

One thing remains that AI cannot replicate on demand: your brand. The name. The identity. The positioning. The reason someone remembers you and not the twelve other founders who built the same thing last Tuesday.

In the pre-AI era, brand was a nice-to-have for early-stage startups. Ship fast, figure out the brand later, rename if you need to. That logic made sense when building was expensive and slow. You spent your time and money on the product because the product was the hard part.

Now building is cheap and fast. The hard part is everything else. And “everything else” starts with a name.

The naming problem nobody fixed

Every founder hits the same wall. AI tools generate brilliant name ideas. You fall in love with one. Check the .com domain. Taken. Try another. Taken. A third. Taken.

It’s a Sisyphus problem. The boulder reaches the top and rolls back down, over and over. The frustration isn’t that AI can’t generate good names. It’s that the vast majority lead nowhere because the domain, the trademark, or the social handles don’t exist.

Most founders solve this by lowering their standards. They pick a name that’s “good enough” because they’re exhausted from the search. They add a prefix, swap a letter, use a .ai instead of a .com. They move on. And they spend the next three years explaining how to spell their company name on every call.

The name is the first thing a customer encounters. It’s the first thing an investor sees. It’s the first thing an AI model encounters when it’s deciding whether to cite your company as an answer to a user’s question. Getting it wrong doesn’t kill the company. But getting it right compounds in ways that are easy to underestimate.

Why brand matters more now, not less

The conventional wisdom says brand is a luxury for early-stage startups. Focus on product-market fit. The brand can come later.

That was true when products were hard to build and easy to differentiate. You could be the only company doing X because building X took two years and a team of twenty. Your product WAS your brand.

In 2026, building X takes a weekend. Five other founders built the same thing. The product is not your brand anymore. The brand is what makes someone choose you over the other four options that do the same thing.

Research consistently shows that trust and authenticity are deciding factors in purchasing decisions. These findings are not new. What’s new is that the product itself can no longer carry the weight of differentiation.

Brand is also how you show up in AI. LLMs don’t browse. They recall what’s embedded in their training data and what they can find on the open web. If your brand isn’t distinctive, well-documented, and consistently presented across every surface, you don’t exist to the AI models that are increasingly mediating how buyers discover products.

This is the Answer Engine Optimisation problem applied to identity. Your brand needs to be legible not just to humans scrolling through a landing page, but to AI agents evaluating vendors on behalf of procurement teams. A generic name with no .com and inconsistent social handles is invisible to both.

What a proper naming process looks like

The agencies that charge six figures for naming follow a process that most founders skip entirely.

They start with constraints. Not “what sounds good” but “what must be true.” Target market: who is this name for? Linguistic requirements: what language, what phonetic patterns? Strategic constraints: should the name suggest a category, or deliberately avoid it? Practical constraints: length, pronounceability, domain availability, trademark clearance.

Then they generate within those constraints. Not “give me 100 random ideas.” Give me ideas that satisfy every requirement simultaneously. The .com must be available. The trademark space must be clear. The social handles must be claimable. The name must work in the target language without negative associations.

This is why the good agencies charge what they charge. The creative work is real, but the filtering work is enormous. Most of the process is elimination, not generation. AI is excellent at generation. It’s terrible at simultaneous multi-constraint filtering because the feedback loops (domain check, trademark search, social handle verification) require real-time external validation, not pattern matching.

The founders who get naming right do it in one concentrated effort. The ones who get it wrong carry the consequences for years.

The first decision that compounds

A brand decision made in week one affects everything that follows. The domain determines your email addresses, your SEO authority, your credibility signal when someone Googles you for the first time. The name determines whether people can remember you, spell you, and find you. The visual identity determines whether your site, your pitch deck, and your LinkedIn presence feel coherent or thrown together.

These are not cosmetic choices. They are structural choices that compound over time, just like architectural decisions in code. A bad name is technical debt for your brand. You can live with it, but it costs you something on every interaction.

In an era where everything else can be built in a weekend, the things that can’t be replicated matter more than ever. Your brand is one of them.

First published on aberlay.com on April 1, 2026.