Vendors Sell Suites. Teams Need Slices. AI Made It Cheap.

There is a story I keep hearing, and I have lived a version of it myself.

We were a small firm. For a long time we had been asking our SaaS vendor for one small feature. Not a roadmap revolution, just one capability that would make daily work less annoying.

We were not a flagship customer. We were not the account that makes a salesperson show up with a deck and free cookies. So the feature kept landing in the same place, the polite back burner.

Then renewal season came close enough that it started showing up in meetings.

At some point we said, before the annual renewal hits, let us try something. A weekend, Cursor, and a couple of LLM chats later, we had the feature we needed and the narrow workflow we actually used. Good enough to replace a license.

I have heard variations of this from other people too. Different tools, different vendors, same pattern. A small slice built internally, not because someone wanted to start a rebellion, but because the economics suddenly made sense.

The counterpoint is always the same.

Vendors are specialists. They can do it better.

They often can. At least, they can build a broader, more polished product for a wider audience.

But that is not the only question.

The question is whether you need the broader product, or whether you need a reliable path through a small part of it.

This is where the internet conversation gets messy. Social media is a terrible place for nuance, and LinkedIn is where nuance goes to die a slow death in front of a ring light.

My blog is my own space, so I can say this the way I want to. This is my take. It might be flawed, but it is mine.

The part everyone argues about, and the part that matters

When people claim they “cloned” a product, they often mean very different things:

1. A UI lookalike
2. A workflow replica that solves one internal problem
3. A full replacement with all the guarantees

Most of the interesting stories today are category two, even when the posts pretend they are category three.

And category two is enough to create pressure.

Most “AI clones” are not trying to replace the product.
They are trying to replace one workflow inside the product.

That is the part worth debating.

Cloning itself is not new. Students have been building clones forever as a way to learn. What is new is the speed. A narrow workflow used to be weeks of work. Now it can be a weekend decision.

Suites lose to slices

Most organizations do not use the full suite they pay for.

They use a portion. A path. A handful of screens. A set of actions that happen every day.

The rest is “nice to have,” or “maybe we will use it later,” or “it came in the package so we pretend it is strategic.”

So when workflow replication becomes cheap, the default conversation changes.

Before, it was “do we buy this product or not.”

Now it becomes “which parts are worth buying, and which parts are cheaper to build ourselves.”

That shift is brutal for business models that depend on bundling.

Vendors sell the bundle.
Internal teams fund the slice.

The ownership tax scales with scope

Yes, if you build internal tools, you own them.

Documentation, stewardship, support rotation, updates, and the occasional “why is this on fire” moment.

But the ownership tax scales with what you build.

A vendor has to maintain the full suite. You do not.

If you replicate a narrow workflow, you are not signing up to maintain 100 percent of the product. You are maintaining the slice you actually use.

This matters because the vendor’s codebase is not “feature logic plus some glue.” A lot of it exists to support the vendor’s business model and the vendor’s constraints:

• Multi tenant isolation
• Generic access control for every possible org shape
• Audit trails and reporting for every compliance checkbox
• Backwards compatibility for old customers
• Integration marketplaces
• Onboarding, training, and support processes
• Billing, entitlements, packaging logic
• “Works everywhere” engineering

Internal tooling can be brutally honest:

• One tenant by definition
• One identity system
• One environment
• One workflow that actually matters
• The freedom to say “we fix what we hit”

If your internal workflow needs a tracker, you integrate the one tracker. If you only care about Jira, you integrate Jira. If your team only wants one notification path, you build one notification path. we use to call it bespoke development.

The tool does not need to impress 100 customers. It needs to save your team time and money.

I am not rebuilding your product.
I am rebuilding my workflow.

A small extra nuance that rarely gets mentioned.

Sometimes the “edge case” is not a missing feature. Sometimes it is you.

I have had scenarios where vendors did not want to take me in as a customer because my scale was awkward for them. They did not want to bend their system for one weirdly shaped customer.

So yes, edge cases take effort.

Sometimes the market chooses not to handle your edge case at all.

Risk did not disappear, it changed shape

We used to talk about key person risk.

“If the person who built it leaves, we are stuck.”

That is still real, but the modern toolchain adds a new flavor.

Toolchain risk.

If the LLM you rely on changes availability, pricing, or behavior, your build loop becomes unpredictable.

So is SaaS a safe space. A hard No, if your SaaS vendor gets acquired, changes terms, or quietly dies in the VC ecosystem, you face churn at renewal anyway.

One way or the other, you plan for churn.

The practical difference is that internal slices let you keep the critical asset, which is the working system and its artifacts.

• You can treat the LLM as an assistant to produce deterministic output.
• You can pin models when it makes sense.
• You can keep generated code in version control.
• You can rely on tests so the tool assists the build rather than becoming a runtime dependency.

Survival Guide for Vibe Coding

My browser first bias made this obvious

Building client side tools taught me something I did not fully appreciate when I was only consuming enterprise software.

The technical logic is often the smallest part.

The rest is scaffolding required to sell, scale, and survive as a product company.

When you are not selling it, you can remove huge chunks of complexity.

No multi tenant gymnastics. No pricing plans embedded inside permission logic. No onboarding flows for strangers. No marketplace of integrations you do not want.

Software gets suspiciously small when you stop trying to make it a business.

This is not a moral statement. It is just math.

And it is why “AI clones” feel more credible now. They are often not clones. They are workflow extracts.

Hardening and attack surface reduction

I am biased here, and proudly so.

I am a believer in attack surface reduction. reducetheattacksurface.com

Less surface is better. Less surface means fewer moving parts.

Fewer moving parts means fewer updates, fewer dependencies, fewer forgotten admin panels, and fewer “wait, why is that exposed to the internet” surprises.

Yes, someone still needs to keep a check on hardening and updates. The difference is that when your tool is a narrow slice, the check is smaller.

Also, we should stop pretending that buying a vendor means hardening is solved. Vendors do not do a stellar job by default. Some do, many do not.

A logo on a contract is not a security control.

The real moat is not technical

There is one vendor advantage that still matters a lot.

Delegation of responsibility, and more importantly, liability.

At some point, especially in regulated industries, you are not buying features. You are buying contracts, auditability, and the ability to transfer certain categories of risk out of the org.

If the question becomes “who pays when this goes wrong,” you are no longer in the realm of engineering. You are in the realm of insurance.

That is a durable moat, and it is also why I do not believe vendors are dying.

What is changing is the default.

What I hope vendors learn from this

If I were selling a product in this environment, I would worry less about “AI cloned X” as a headline and more about unbundling as a trend. This is also consistent with the natural flip cycles of computing

Customers are going to ask harder questions:

• Which workflows are we actually paying for
• Which workflows can we replicate with acceptable risk
• Why are we paying for integrations we do not use
• Why does “enterprise grade” feel like “enterprise bloat”

The winning vendors will probably be the ones who embrace this reality instead of fighting it.

Modular pricing.

Clean APIs.

Exportability that does not feel like a hostage negotiation.

A product that earns its cost on workflows customers actually value, not on the fear of migration.

Where I personally landed

I do not think AI assisted workflow replication means the end of vendors.

I do think it means vendors will have to justify their bundles in a way they did not have to before.

And I think a lot of organizations will quietly build internal slices, not because they are rebelling, but because they are budgeting.

If you are thoughtful, you can keep scope small, keep the workflow tight, and keep the value obvious.

Cloning is not the revolution.
Scoping is.