Coding got cheap. Engineering didn’t.

TL;DR:#

Someone built a task app on localhost and declared SaaS dead. They didn’t build a product, they built a solution. AI made coding cheap, but it didn’t make engineering, running a product, or building a company any easier. A SaaS isn’t just code. It’s security, infrastructure, design, support, sales, billing, and the person who picks up the phone at 2am when it breaks for a paying customer. Some categories are genuinely at risk: personal, one-size-fits-one tools and thin AI wrappers. The corporate, complex, embedded ones are fine, protected by trust, compliance, integrations, and the cost of switching. SaaS doesn’t die. It adapts. If you built something for yourself and it works, good. Just don’t confuse it with a company.

Someone in one of my professional groups dropped this message a few weeks ago:

“I built Monday. No wonder they’re dead.”

Attached was a screenshot. A task app. Running on localhost.

Some people pushed back. Others nodded along and started talking about how you can build any SaaS yourself now, and the whole model is finished.

I’ve been thinking about that conversation since.

What actually happened there#

That person built a solution. A small, specific, functional answer to a need they had. That’s real, that’s useful, and good for them.

But they didn’t build Monday.

Monday has multi-workspace management, granular permissions, cross-team sharing, guest access, automations, integrations with dozens of tools, a mobile app, an API, SOC 2 compliance, SLA commitments, a support team, a sales team, a pricing model, a billing system, and about 200 engineers who wake up every morning thinking about the product.

What got built was a to-do list that works for one person on one machine.

That’s not a criticism. That’s just what it is. A solution. Not a product.

The problem isn’t that people are building things. That’s great. The problem is the story they tell themselves about what they built.

The concrete vs the structure#

Here’s how I think about the difference.

Knowing how to mix and pour concrete doesn’t make you a structural engineer. You can fill a form, get it to set, and have something solid under your feet. It works. But planning for load distribution, long-term stress, seismic tolerance. That’s a different discipline entirely.

Same thing here. Writing code that runs is not software engineering. It’s a start, but it’s not the same thing.

Engineering is designing something that survives contact with reality: scale, failure, misuse, time, and other people.

AI coding tools made the “pour the concrete” part far cheaper and more accessible. That’s useful. But they didn’t make structural engineering easier. That part is still hard, still requires judgment, and still requires experience that doesn’t come from a good prompt.

Building a solution vs building a product#

When I built gh0wst, a tool for my research team to track and manage conference talk submissions, I built a solution.

It does exactly what we need. Personal tracking per researcher, auto-updating conference details, LLM-powered abstract review, Slack notifications for deadlines and acceptances. Built in an evening with Claude. Deployed to our cloud. Behind our SSO.

It’s useful. My team uses it every day.

But if I wanted to turn it into a product, something I sell to other security teams, the list of what I don’t have yet is brutal:

Features other teams need that we don’t. UI and UX actually designed for people who aren’t me. Marketing. A sales motion. Pricing. Licensing. A way to handle billing. Infrastructure that scales beyond one team. Security designed for multi-tenant use. A support process. Someone responsible for it when it breaks at 2am for a paying customer.

None of that is in the code. None of it comes from a good Claude Code session. All of it is the product.

Nobody is a master of everything#

Here’s the thing that usually gets missed in this conversation.

Even if you’re technical enough to build something solid, the people saying “SaaS is dead” tend to be excited about the coding part. The part they know.

But a SaaS company isn’t just code. It’s code plus security plus infrastructure plus design plus support plus marketing plus sales plus legal plus finance plus operations.

If you come from a technical background, you might build something that runs well and is reasonably secure. But you’ll probably struggle with GTM. You’ll underestimate how long it takes to get someone to pay for something. You’ll find out that getting a corporate client to cut a check requires a company, a contract, procurement approval, a security review, and a relationship.

If you come from a business background, you might have the GTM figured out. But the code will probably have auth problems you aren’t aware of. The infra won’t scale when you need it to. The security gaps won’t be obvious until someone finds them.

Nobody is a master of everything. That’s why companies have teams.

The hidden cost people don’t post about#

There’s a specific pattern I keep seeing.

Someone builds a tool. Posts about it. Gets a bunch of engagement. “Built X in a weekend, never paying for Y again.”

Six months later: silence.

Because they didn’t post the follow-up. The one where a library update broke something and they spent a Saturday debugging it. The one where a teammate needed a feature and they had to almost rebuild the whole thing because the original design didn’t account for it. The one where they wanted to add something and realized the AI had no idea why certain architectural decisions were made three months ago, because that context wasn’t documented anywhere, and now fixing it means breaking other things.

I’ve lived this myself. I’ve built tools that I’m now the accidental maintainer of. Sometimes a fix takes ten minutes. Sometimes you don’t know how long it’ll take, and that unpredictability is worse than a fixed cost, because you can’t plan around it.

A SaaS subscription costs money. An internal vibe-coded tool costs time. And time is the one thing you can’t buy back.

The “good enough” problem#

Here’s the honest version of my own situation.

There are SaaS apps I’ve thought about replacing. Workout tracking. Calorie logging. A few other personal things.

I haven’t. And the reason isn’t that I couldn’t build something. It’s that the free tier of whatever commercial app I’m using is good enough. Good enough for my needs, right now, with zero maintenance burden on my side.

So the “I’ll just build it” crowd isn’t really competing against SaaS subscriptions. They’re competing against free tiers. That’s a different fight, and it changes what “winning” looks like.

Where the SaaS fear is legitimate#

I don’t want to be dismissive here, because some of the concern is real.

There are SaaS categories that are genuinely vulnerable. Mostly the ones where:

  • The audience is private individuals paying for themselves, not companies
  • The core product is inherently personal and one-size-fits-one: a website, a workout plan, a simple dashboard
  • The “product” is basically a wrapper around something you could prompt an AI to do directly

Think Wix. Think basic content generation tools. Think simple scheduling apps. These are at real risk, and some of them probably won’t survive the next few years in their current form.

The corporate tools, the complex workflow platforms, the ones embedded into how organizations function, those are fine. Not because they’re immune to disruption, but because the thing protecting them isn’t code. It’s trust, compliance, scale, integrations, and the organizational cost of switching.

What’s coming#

My honest guess about where this goes: SaaS doesn’t die. It adapts.

The interesting next move is SaaS that helps you build your own solutions, abstracting away the parts that are still hard. Not “here’s a prompt box, build your thing,” but “describe what you need, and we’ll handle the deployment, the auth, the scaling, the billing hooks, the analytics.” An orchestration layer for solution-building.

The early pieces of that exist. MCP integrations, built-in tooling inside AI coding agents, some of the newer no-code-adjacent platforms. It’s fragmented and still rough. But the direction is clear.

AI didn’t kill SaaS. It’s going to change what SaaS sells.

The takeaway#

Building something that does what Monday does for you personally is not the same as building Monday.

You answered your own need. That’s valuable. That’s real. There’s nothing wrong with it. If you have a specific need and the free tier of a commercial tool doesn’t cover it, building your own solution is probably the right call.

But you didn’t build a product. You built a solution.

A solution is local, specific, limited, and built for you.

A product is designed for an audience you’ve never met, with needs you haven’t anticipated, running on infrastructure you’re responsible for, covered by a support commitment you made, priced in a way that sustains a business, secured against people who want to break it, and maintained by people whose job it is to keep it alive.

Coding got cheap.

That part is true.

Engineering didn’t. Running a product didn’t. Building a company didn’t.

The guy on localhost didn’t build Monday.

He built something for himself. That’s fine. That’s the point.

“In theory, there is no difference between theory and practice. In practice, there is.” – Benjamin Brewster

logo