There is a certain kind of LinkedIn post that gets celebrated far too easily.
A founder posts a screenshot of a jam-packed calendar. Every hour blocked out. Discovery calls. Demos. Follow-ups. Maybe a caption about “grateful for the demand” or “crazy times ahead.” Everyone claps. Everyone assumes this is what success looks like.
I understand why. We have had that too.
And honestly, it does feel good. A full calendar is validating. It tells you the market is listening. It tells you your messaging is landing. It tells you people want something from you.
But I think founders need to say this more clearly.
A busy calendar is not an achievement. It is not a business. In many cases, it is just visible chaos.
This is one of the harder lessons we are learning right now. Generating demand is important. Getting meetings is important. But meetings alone prove almost nothing. What matters is whether there is a system underneath that can turn that interest into something repeatable, measurable, and scalable.
Without that system, a fully booked calendar is just founder theatre.
It looks like momentum from the outside, but inside the business it can be hiding all kinds of weakness. Weak qualification. Weak follow-up. Weak handoffs. Weak note capture. Weak ownership. Weak conversion discipline. Weak feedback loops. Weak onboarding. Weak retention. Weak product learning.
In other words, the calendar fills up, but the company does not actually get stronger.
That is the trap.
A lot of people confuse activity with progress because activity is easier to show. It is easy to post a screenshot of demand. It is much harder to show the quality of the pipeline, the consistency of the sales process, the speed of follow-up, the cleanliness of the CRM, the conversion by source, the sales-to-onboarding handoff, or how many insights from customer conversations actually made it back into product and operations.
But those are the things that matter.
Anyone can brute-force their way into a busy week. A founder can personally handle every call, push every follow-up, remember every detail in their head, and create the appearance of momentum. For a while, that works. In fact, in the early days it often has to work.
But founder heroics do not scale. Adrenaline is not infrastructure.
Sooner or later, a full calendar stops feeling like validation and starts feeling like pressure. You realise the issue is no longer getting attention. The issue is what happens after attention arrives. If every lead depends on one person, if every deal moves differently, if every next step is improvised, if notes are incomplete, if no one can tell where conversion is leaking, then more meetings are not helping. They are exposing the fragility of the business.
This is why I have become much less impressed by booked calendars.
I care more about whether the company has a machine.
Can the right leads enter consistently? Can they be qualified properly? Can they be routed correctly? Can meetings be prepared for with context? Can objections be captured and turned into better messaging? Can next steps be enforced? Can handoffs happen cleanly? Can the business learn from every conversation? Can the team produce the same quality outcome without the founder sitting in the middle of everything?
That is what a real company looks like.
The real flex is not that your calendar is full. The real flex is that your system is strong enough to deserve that demand.
Because meetings are expensive. They cost time, energy, attention, and opportunity cost. If your system is weak, then a full calendar is not a trophy. It is a liability. It means more dropped balls, more inconsistent experiences, more pipeline leakage, and more false confidence.
And that false confidence is dangerous. It tricks founders into believing they are scaling when they are actually just getting busier. It makes teams optimise for visible activity instead of underlying quality. It creates companies that look hot from the outside and feel brittle from the inside.
A booked calendar should be seen for what it is: an input, not an outcome.
The outcome is revenue. The outcome is conversion. The outcome is retained customers. The outcome is a team that can execute repeatedly. The outcome is a system that gets smarter every week because demand is being processed, not just received.
So yes, I still think a full calendar is worth appreciating. It means you have earned some attention, and attention is hard to win.
But attention is fragile. Systems compound.
That is the shift in thinking I wish more founders talked about. Not how to make the calendar look full, but how to build the operating system behind it. Not how to collect meetings, but how to make meetings matter. Not how to appear busy, but how to become structurally effective.
We have achieved the fully booked calendar.
Now we are learning the harder lesson: the calendar was never the goal.
The system is.
]]>For the last two decades, most software has followed a familiar model: give users a structured system, expose a set of configurable features, and let them decide how to use it.
This is the mental model of traditional SaaS.
CRMs, project management tools, marketing automation platforms, help desks, design tools, and analytics products all largely work the same way. They provide primitives: fields, tables, workflows, filters, permissions, dashboards, buttons, forms. The user decides what to do. The software stores, displays, and routes information. In many cases, the software becomes more valuable as it becomes more flexible.
But AI-enabled applications, especially those built around large language models, are different.
They do not just store and present information. They interpret, infer, decide, rewrite, recommend, and increasingly act. That changes the nature of software itself.
What many people still haven’t fully realised is this:
LLM-integrated apps are fundamentally more opinionated than traditional SaaS.
This is not a minor product detail. It is one of the deepest shifts in software design.
And it has major implications for how AI products should be built, sold, evaluated, and trusted.
Traditional SaaS waits for explicit input.
The user chooses a pipeline stage. The user fills in the form. The user writes the email. The user creates the automation. The user configures the dashboard. The user decides what happens next.
Even when traditional SaaS is powerful, it tends to be passive. It is usually a tool for expressing user intent, not generating it.
A CRM does not tell you what to say to a customer in a nuanced way. A spreadsheet does not decide what the business should prioritise. A help desk platform does not autonomously interpret customer emotion and draft the right response in your brand voice. A project management tool does not usually resolve ambiguity on your behalf.
Traditional SaaS can be highly configurable, but the burden of judgment still sits with the human.
That is why classic software products often win by being horizontal, flexible, and extensible. They are designed to support many workflows because they do not deeply commit to one interpretation of what the user is trying to do.
Once you place an LLM inside an application, the product begins to do something different.
It starts converting ambiguous human input into structured output.
That sounds simple, but it is profound.
A user says:
These are not explicit software instructions in the traditional sense. They are fuzzy, contextual, incomplete, and subjective.
For the application to respond well, it must make judgments.
It must decide:
The moment software starts doing that, it stops being neutral infrastructure.
It becomes opinionated.
A traditional SaaS app can often succeed by being configurable enough for the customer to shape it.
An AI-enabled app cannot rely on configuration alone, because intelligence is not just infrastructure. Intelligence is judgment applied under ambiguity.
And judgment requires embedded assumptions.
For an AI app to produce consistently useful output, the builder must decide things like:
This means every serious AI product contains a hidden philosophy.
Even if the interface looks simple, beneath it is a stack of opinions:
This is why two AI products built for the same category can feel radically different even if they use similar underlying models.
The model is not the product.
The product is the set of opinions wrapped around the model.
This is one of the clearest differences.
Traditional SaaS often sells empowerment through control:
The product’s value comes from giving users tools to create their own system.
AI-native apps tend to sell something else:
The value is less about control and more about compression of effort.
The promise is not “here is a system you can operate.”
The promise is “here is a system that can think with you, and sometimes for you.”
That promise is stronger. But it is also more dangerous.
Because the more an application promises outcomes, the more the user has to trust the product’s judgment.
And trust is where opinionated design becomes unavoidable.
In traditional SaaS, good design mattered, but product taste mostly lived in UX, information architecture, and workflow simplicity.
In AI products, taste moves much deeper into the product.
Now taste affects:
This is a big shift.
In LLM-native applications, the product team is no longer just designing screens and workflows. They are designing judgment.
They are deciding what “good work” looks like.
That means the best AI products are not just technically strong. They have strong product taste, editorial taste, operational taste, and domain taste.
A mediocre SaaS product can still survive by being flexible and letting the customer do the hard thinking.
A mediocre AI app collapses much faster, because weak judgment is visible immediately.
It shows up in every answer, every draft, every recommendation, every action.
There is a common assumption that software should become more general, more flexible, and more neutral over time.
That was often true in the SaaS era.
But in the AI era, more useful software may actually become less neutral.
Why?
Because the user is no longer only buying a tool. They are also buying a point of view.
When someone uses an AI SDR, they are implicitly accepting a view of what a good sales process looks like. When they use an AI recruiter, they are accepting a view of what makes a candidate qualified. When they use an AI writing assistant, they are accepting a view of what good writing sounds like. When they use an AI CRM copilot, they are accepting a view of how customer relationships should be prioritised and handled.
This is why domain-specific AI applications are so powerful.
They do not just add AI to generic workflows. They encode a worldview about how work in that domain should be done.
The strongest products will not be the most general ones. They will be the ones with the clearest and most correct opinions for a particular job.
Many software buyers have been trained by the SaaS era to ask for configurability.
They ask for:
And some of that still matters.
But in practice, many users do not actually want infinite flexibility. They want confidence that the software knows what it is doing.
They want:
This creates tension inside AI product design.
If you make the product too opinionated, users may feel constrained or mistrust the system.
If you make it too configurable, you push the burden back onto the user and lose the main advantage of AI.
The winning AI products will likely find a new balance: strong default opinions, with selective override points.
Not infinite flexibility. Not rigid automation. But guided intelligence.
Many teams are currently shipping “AI features” into existing SaaS products without acknowledging this underlying shift.
They add:
But they still think like SaaS builders.
They assume the user will define the workflow and the AI will simply assist inside it.
That is often not enough.
Because once AI enters the product, the real design challenge is not just feature placement. It is judgment design.
Builders now have to answer harder questions:
These are not secondary details. They are the product.
In the SaaS era, product teams could sometimes hide behind flexibility.
In the AI era, they must pick a side.
Customers also need to become more sophisticated in how they evaluate AI products.
The old SaaS buying checklist focused on integrations, permissions, reporting, pricing, implementation, customisation, security, and support.
Those still matter.
But with AI products, buyers should also ask:
In other words, the question is no longer just “what features does this software have?”
It is also: “What worldview is this software asking me to adopt?”
That is a very different procurement question.
One useful mental model is this:
Traditional SaaS is like buying equipment. AI-enabled software is increasingly like hiring a teammate.
And when you hire a teammate, you do not only care about capability. You care about judgment, reliability, communication style, initiative, trust, and values.
That is exactly where AI applications are heading.
We will increasingly evaluate software not just on features, but on qualities that used to belong to people:
This is why AI products feel more personal, more powerful, and more risky than traditional SaaS.
They are not just systems of record.
They are systems of interpretation and action.
And systems of interpretation are never neutral.
The most important shift in AI-enabled applications is not that software can now generate text.
It is that software is starting to make decisions under ambiguity.
Once that happens, software inevitably becomes opinionated.
That is not a flaw. That is the point.
The best AI products will not win because they have the biggest models or the most features. They will win because they embed the right opinions: about quality, workflow, trust, tone, autonomy, and outcomes.
Traditional SaaS helped users operate software.
AI-native applications will increasingly help users operate reality.
And the companies that understand this early will build products that feel less like tools, and more like high-judgment teammates.
]]>For two decades, the logic was simple: Buy, don’t build. Engineering talent was too scarce to waste on internal CRMs. So, we rented. We paid monthly subscriptions for generic software that solved 80% of our problems and created 20% new ones.
But that economic equation has just inverted.
As noted in the viral “SaaS is Dying” thesis circulating in VC circles, and echoed by reports from CTech, we are witnessing a fundamental shift. With the rise of “vibe coding” (natural language programming) and agentic workflows, the marginal cost of writing software is racing toward zero.
If you can build a bespoke, enterprise-grade internal tool in a weekend with an AI agent, why would you pay $50k a year for a rigid SaaS contract?
“B2B SaaS” isn’t dying because we don’t need software. It’s dying because the Rent-vs-Build arbitrage is gone.
So, what happens next?
We are moving from buying buildings to buying bricks.
Future companies won’t buy a monolithic CRM like Salesforce. Instead, they will adopt what Gartner defines as the Composable Enterprise. They will buy:
They will then have their internal AI agents stitch these components together. The next unicorn won’t sell a “Platform”; they will sell the high-fidelity ingredients that allow companies to bake their own cakes.
The B2B SaaS model sold you a tool to make employees efficient. The next model sells you the outcome.
This is the “Service-as-Software” thesis pioneered by Foundation Capital. We won’t subscribe to accounting software; we will subscribe to an “AI Accountant” that lives in our cloud and just does the work.
The value metric shifts from Seats (User Licenses) to Work Done (Outcomes). As seen with Salesforce’s Agentforce pricing and Intercom’s Fin AI, companies are beginning to charge per conversation or resolution, not per login. You aren’t paying for the interface; you are paying for the execution.
This is the biggest shift. Companies will return to owning their software.
Data privacy and IP leakage are the new existential threats. With giants like IBM launching “Sovereign Core” and NVIDIA championing Sovereign AI, the market is signaling that companies can no longer afford to pump proprietary data into a multi-tenant SaaS black box.
The future is Single-Tenant by Default.
The “vendor” of the future provides the blueprint, but the software lives in your house.
The era of the “Generic Wrapper” is over. If your SaaS product is just a slightly better UI over a database, you are now competing with your customer’s internal engineering team—and thanks to AI, that team just got 100x faster.
We aren’t entering a world without software. We are entering a world where everyone is a software company.