Here’s the honest version: a lot of SaaS doesn’t feel like “software as a service” anymore. It feels like “rent a single feature forever.”

And when the bill hits three digits a month for something you use twice a month, the value calculation gets weird fast.

What changed is not pricing. Pricing has always been… ambitious.

What changed is that it’s now normal for designers and small teams to build their own utilities. Not as a science project. As an actual workflow. Tools like Cursor, Claude Code, and Lovable took a big chunk of friction out of going from “we need this” to “it exists.”

I’ve started calling this posture anti-SaaS.

Not “SaaS is evil.” Not “never pay for software.” Just: stop subscribing to bloated platforms when you only need a narrow, clear piece of utility.

What I mean by anti-SaaS

Anti-SaaS is the practice of building a Minimum Valuable Utility (MVU) instead of subscribing to a full platform.

A lot of teams don’t have a tooling problem. They have a clarity problem.

• What is the single job this tool needs to do?
• What is the minimum experience required for that job to be usable?
• What parts of the SaaS product are “nice,” but not necessary for your workflow?

When you answer those honestly, you start seeing how much of a typical SaaS plan is padding.

The moment it clicked: client review broke the workflow

We’ve been shipping more web and brand experience work as live artifacts.

Not PDFs. Not a Figma file that slowly drifts away from reality. Actual deployed pages. Vercel links. Real code. Real iteration.

That workflow is great until you hit the most basic question:

How does a client leave comments on the actual site?

Developer tools are amazing at deployment and versioning. They’re not great at client-facing feedback. And the tools that are great at feedback often come with a familiar trade:

• free trial
• strong onboarding
• “starts at” pricing that assumes you’re a 40-person product org
• $300/month because you want… commenting

So we took the anti-SaaS route.

We built the minimum.

What we built (MVU version)

A simple tool that:

• lets you drop any URL
• generates a share link for the client
• lets them enter their name and email
• lets them leave comments directly on the page
• gives us a clean way to action and track feedback

That’s it.

No “workspace.” No seats. No admin console that needs a training session.

Just the utility taylor fit to the workflow.

The pattern that mattered: vibe-code fast, then harden

I’m not precious about how the first version gets made.

We got to a working prototype quickly using an AI-assisted build approach (what the internet calls “vibe coding”), and then we tightened it up with real development discipline.

That sequencing matters:

1. Prototype like you’re sketching.
2. Apply a taste layer.
3. Harden like you’re shipping.

My honest observation: prototypes are allowed to be messy. Production isn’t.

One MVU leads to another

Once you’ve built one “we only need this one thing” tool, your brain starts noticing how many other workflows are held hostage by subscriptions.

The next pressure test showed up in brand delivery.

More clients are asking for brands that are AI-native in a practical sense:

• “Cool brand guidelines. But how do I make a landing page in lovable and keep it on brand?”
• “How do I generate ad copy without drifting off voice?”
• “How do I generate images in our style?”

The work has been shifting over the past few years. Brands need to be living artifacts that plug directly into the tools people are using.

So we asked a different question:

What if the brand kit is also a tool?

The second build: living brand guidelines as an artifact

We started building an internal platform that turns the end of a brand sprint into something usable on day one:

• Pull in the actual deliverables from the sprint (strategy decks, Figma prototypes, design tokens, voice and tone markdown files)
• Ingest them automatically and structure them into a living set of guidelines
• Make assets instantly accessible and downloadable
• include the core prompts, custom tools, and files that help clients build where they already we're without losing taste

It’s another anti-SaaS move: instead of buying a generic “brand guidelines platform” and bending our process around it, we built a tool that fits how we actually ship.

‍

The broader point: SaaS is turning into “software for a use case”

I’m not making the claim that subscriptions disappear tomorrow.

I am saying this: the default is shifting.

When building gets cheaper and faster, the SaaS model gets pressure-tested in a new way. Not by competitors. By customers who can now build a narrower tool that fits their exact workflow.

This is showing up outside design studios too. “Vibe coding” is getting pulled into enterprise conversations precisely because it enables teams to build internal tools instead of buying them.

And AI coding tools are being adopted at serious scale, which only accelerates the expectation that “custom” can be normal.

The nuance: this doesn’t kill SaaS. It shrinks it.

It turns a lot of “platforms” into a set of features that customers can choose to rebuild when the math stops working.

A simple anti-SaaS test (use this before you build anything)

If you’re a designer, agency operator, or small team, here’s what I’d run before you open another free trial.

1) Is the job narrow and stable?

If the use case is clear and not changing weekly, it’s a good MVU candidate.

2) Are you paying for features you don’t touch?

Be honest. If you only use 10% of the product, you’re buying someone else’s roadmap.

3) Does the tool sit at the edge of your workflow?

Edge tools are perfect MVUs: commenting, handoff, internal QA, asset management, intake forms.

4) Would a custom tool create quality, not chaos?

If the tool helps you ship with more consistency, less cognitive load, and fewer steps, it’s worth it.

5) Can you maintain it without becoming a software company?

If building it means you now have a second job, pause. Sometimes the subscription is still the right call.

When to still pay for SaaS

Anti-SaaS is not a purity test. There are categories where SaaS wins:

• High compliance and security requirements
• Deep integrations you don’t want to own
• Infrastructure you don’t want to maintain (payments, auth at scale, analytics pipelines)
• Anything where the cost of failure is massive

Taste is still a competitive advantage, and restraint applies here too.

Building the wrong thing is just a different kind of waste.

What I think happens next

My bet: we move from “software as a service” to Value-as-a-Service (VaaS).

• You subscribe to fewer platforms.
• You assemble more small utilities.
• You build the missing pieces when the workflow demands it.
• You treat tools like artifacts, not commitments.

And for designers specifically, this is a shift in power.

You’re not just designing screens. You’re designing workflows, handoffs, and living systems that keep the brand intact when the client is moving fast.

If you only try one thing

Pick one recurring annoyance in your workflow. Something small but constant.

Then build the minimum version of the utility that removes it.

A small experiment:

• write the one-sentence job the tool needs to do
• list the 3 actions a user must be able to take and cut everything else

• Create a PRD (Product Requirements Document) to get you started with AI
• Prototype Fast with tools like (Cursor or Claude Code)
• Add your own touch (AKA the taste layer)
• Harden what sticks with human developemnt (so you dont push your API key to git)