DEV Community

Florian Gilde
Florian Gilde

Posted on

R.I.P. SaaS

Or: how one small experiment confirmed a suspicion I've had for a while.


My sample starts with a missing demo for a DB UI.

But this story isn't really about a database GUI.

For some time, I've had the feeling that we're approaching a point where traditional SaaS products become less necessary—not because software disappears, but because the way we create and consume it is fundamentally changing.

The missing database tool simply became the perfect excuse to test that hypothesis. I followed the idea all the way through, treating it as a small experiment. Then, just for fun, I repeated the same process with a handful of completely different applications.

The results surprised me. Not because the database GUI was special, but because it turned out to be just another example of a much larger pattern.

It started with a missing demo

I was building a .NET Aspire stack and wanted the boring thing every stack needs eventually: a database UI. Not a desktop client I install once and forget on my own machine — something I can drop into the app host as a resource, hand a connection string via environment variable, and open in a browser tab next to the Aspire dashboard. Same lifecycle as everything else in the stack. Gone when the stack goes down.

I looked. I really did look. Web-based database tooling is a thinner field than you'd expect in 2026. Most of what came up was either a desktop app with a web skin bolted on, a hosted service that wants my production credentials on someone else's server, or an "enterprise" product with a Contact Sales button where the download link should be.

The one thing that genuinely fit was DBGate. Good project, real open source, docker image, does the job. So I opened the demo to see the UI before committing.

The demo didn't work.

That's it. That's the whole inciting incident. A broken demo page.

The version of me from three years ago would have shrugged, pulled the image, spun it up locally, poked around for twenty minutes, read the docs, worked out how to wire the connection strings, discovered which of the things I wanted weren't supported, opened an issue or two, and eventually made it work. Half a day, maybe a day. That's what you do. That's the job.

Instead I thought: I'll just prompt one.

Not "I'll build one." Prompt one. With exactly the env-var contract I wanted, so it drops into an app host in one line. That is a different sentence from the one I would have thought in 2023, and the difference between those two sentences is the entire point of this article.

The thing I got

WebDataStudio. Docs are live, source is on GitHub, image is on GHCR.

docker run -d -p 8080:8080 -v wds-data:/data \
  -e WDS_CONN_LOCAL="postgres://app:pw@db:5432/shop" \
  ghcr.io/fgilde/webdatastudio
Enter fullscreen mode Exit fullscreen mode

Nine engines in one container — PostgreSQL, MySQL/MariaDB, SQL Server, SQLite, Oracle, DuckDB, ClickHouse, MongoDB, Redis. No login screen unless you set WDS_USER and WDS_PASSWORD, because on a dev stack a login screen is a speed bump, not security.

WebDataStudio query editor: Monaco with dialect-aware highlighting, a result grid with Grid / Form / Transposed / Chart / Compare views, and structure plus execution-plan panels on the right

Here's the part that annoys me: it does more than I needed. Considerably more. There's a visual query builder that draws the join graph and generates the SQL. ER diagrams with PNG and SVG export. Schema and data diffs between two connections, with the sync script in a diff editor. An index advisor that reads the actual execution plan, finds the missing index and writes the CREATE INDEX for you. Spreadsheet-style cell editing that shows you the change script before it runs anything. Twenty-one themes, because why not.

Visual query builder — tables on a canvas, the join drawn as an edge between them, generated SQL updating underneath and the result grid below that

I have paid for commercial tools that do less. I'm not going to name them; you know the ones. Some of them are excellent. But in the parts of the job I actually care about, several of them are now behind a thing I made because a demo page was down.

That's the whole article, really. Everything below is me trying to work out how I feel about it.

The pattern, once you see it

WebDataStudio wasn't a one-off. Once the friction of "should I build this or find something?" drops to roughly zero, you stop asking the question. You just build it. And then you look at your own GitHub profile and there is — this:

What What it replaces Where
AspireUI Aspire tooling plus a PaaS control plane repo · writeup
PveWelcome A homelab dashboard I kept not finding writeup
HaVeWa German property-management software repo · writeup
Coworkee Personio / HR Works repo · writeup
Audiola A DAW plus three separate AI audio tools repo · writeup
Videola A browser video editor repo · writeup
WebDataStudio A web database studio repo · writeup
PowerClean CCleaner plus WinDirStat repo · writeup
MuseForge A shelf of hosted AI media services repo · writeup

Each of those has its own article, because each is a real thing with real docs, real screenshots and a real container image, and flattening them into a bullet list does them a disservice.

Every one of them exists because a subscription didn't fit, a demo was broken, a pricing page had a Contact Sales button, or — most often — because building it was simply faster than evaluating the alternatives.

Read that last clause again, because it's the one the industry should worry about. It isn't that building got cheaper than buying. It's that building got cheaper than shopping. The evaluation phase — trials, feature matrices, the call with the AE, procurement, the security questionnaire — now costs more than the product does.

What actually dies

I don't think all software-as-a-service dies. Let me be precise about which parts I think are already terminal.

The thin wrapper is dead. If your product is a decent UI over a well-documented API, a job scheduler and a Postgres, you have a problem. That's a weekend now. Not because AI is magic, but because that shape of product is almost entirely composed of solved sub-problems, and the assembly work — the part that used to be the moat — is precisely the part that got cheap.

The "we host it so you don't have to" pitch is thinning fast. This was always the strongest SaaS argument and it still has teeth at real scale. But look what happened in my own basement: AspireUI's Hosting feature, a Proxmox box and Nginx Proxy Manager add up to a personal PaaS. One command on the PVE host gives me a VM running AspireUI. From there apps get installed from a store, get a URL, get start/stop/update/backup. I did not learn networking to do that. I learned nothing to do that, which is the disturbing part.

Per-seat pricing on internal tools is walking dead. Coworkee exists because HR software is priced per employee per month, forever, for what is technically a CRUD app with an approval workflow and an org chart. I'm not claiming Personio is only that — they have compliance, payroll partners, support, and a decade of edge cases in German labour law. I'm claiming the 80% a fifteen-person company actually uses is now buildable in a weekend, and the remaining 20% isn't worth a monthly fee per head.

What survives: anything where the value is data you don't have (market data, benchmarks, aggregate signal), anything where the value is liability transfer — payroll, tax filing, compliance sign-off; I want a company on the hook there, not a container in my basement — anything with genuine network effects, and anything at a scale where "just self-host it" is a sentence only an idiot would say.

Notice how short that list is next to the current SaaS landscape.

The part where I'm honest about my ego

I've been a developer a long time. Long enough that my oldest still-public repo is a Visual Studio Team Explorer extension — CheckoutAndBuild, for local CI runs before check-in, back when "check-in" was the word people used. Long enough to have written a Blazor component library, MudBlazor.Extensions, that other people actually depend on: 328 stars, real issues from real strangers, NuGet downloads I didn't drive myself.

I was proud of that. Uncomplicatedly proud. Not for the stars — for the craft. Someone hit a hard problem, came looking, and the thing I wrote solved it. That's the entire reward loop of this profession and it worked on me for two decades.

Now I look at WebDataStudio, which is objectively a larger and more useful piece of software than anything I ever built by hand in a comparable stretch of time, and I feel… not much? Satisfaction that it works. Some real pride in the taste calls — knowing connection strings belong in env vars, that a driver should declare its capabilities so the UI can hide the button that would fail, that a change script must be shown before it runs. Those were mine. That was twenty years of scars talking.

But the code isn't mine the way code used to be mine. And the honest truth is that the code was never the part anyone else valued. It was the part I valued.

There's a specific kind of grief in that. Not "AI took my job" — I'm shipping more than I ever have. It's closer to being a very good typesetter the year desktop publishing arrived. The typography knowledge is still worth something. The muscle memory is worth nothing. And nobody outside the trade can tell the difference, which is somehow the worst part.

I keep turning the reverse case over too. In five years, will anyone be able to tell the difference between software built by someone with twenty years of scars and software built by someone with none? Right now I think yes, clearly, and the difference shows up in exactly the places I listed — the taste calls, the security defaults, the "show the change script first" instinct. In five years? I genuinely don't know. That uncertainty is new for me and I don't like it.

What this does to open source, which is worse

Here's the part I find genuinely bleak, and it isn't about jobs.

Open source ran on a simple loop. You hit a problem. You searched. You found a library. It mostly worked. You used it, and because you used it you cared, and because you cared you filed an issue, sent a PR, wrote a blog post, answered a question, left a star. The maintainer saw people using the thing and kept going. Attention flowed back to effort. That's the engine.

That loop is coming apart at the first step, because people don't search any more. They ask. And what comes back isn't "here's a library that solves this," it's the solution, inlined. Two hundred lines that do the specific thing you asked for, generated by a model that learned the pattern from — yes — that library.

The library got used. The library got no credit, no issue, no star, no PR, no maintainer dopamine and no new contributor.

I can see this in my own behaviour and it makes me uncomfortable. I reach for fewer dependencies now, not out of principle but because the marginal cost of "just write it" collapsed. Every time I do that I'm quietly extracting value from an ecosystem I've stopped feeding. Multiply by every developer and the shape becomes clear: maintainers keep paying the cost, and the returns — the visible ones, the ones that make unpaid work feel worth doing — get routed elsewhere.

The end state, if the trend simply continues, is that GitHub becomes a training index. Not a place where people find and use software. A corpus. A very large, well-labelled, license-annotated pile of solved problems whose primary consumer is a model helping someone build the 200-line version instead of importing yours.

And the awful bit — the bit that makes this a real bind rather than just a complaint — is that it's useful. Enormously. Every project in that table stands on a mountain of open source: Monaco, React Flow, Prisma, Avalonia, Demucs, FFmpeg, Rust, Postgres, .NET, Next.js, Whisper, Tailwind. Half of it I never consciously chose; it simply arrived as the obvious way to do the thing. I am the beneficiary of an ecosystem whose incentive structure I'm helping to dismantle, and I don't have a clean answer to that.

I keep waiting for someone smarter than me to propose a mechanism. Attribution that survives generation. Some way for a model's output to route credit back to what it learned from. Nothing I've seen is close to workable at the scale it would have to work at.

Why I find the future frightening, specifically

Not the science-fiction version. I don't lie awake about superintelligence. Three concrete things:

Nobody knows what anything costs any more. I can produce, over a long weekend, a thing that would have been a funded startup's first year. That's not a boast, it's a pricing catastrophe. If a competent person with good taste can produce a credible competitor to your product in four days, what is your product worth? What is my time worth? I used to be able to quote a project. Now I genuinely can't, and neither can the client, and we both know it.

The apprenticeship is broken. I got good by doing years of boring, badly-paid, mid-level work — the CRUD screens, the migration scripts, the flaky test nobody wanted to own. That work is exactly what's being automated first. The path I walked to earn the taste I now use to steer these tools is being removed, and I have no idea what replaces it. I have twenty years of pattern-matching I can't teach and the next person can't earn.

I can't verify what I ship as fast as I can ship it. This is the one that actually costs me sleep. My throughput went up maybe tenfold. My ability to read code, hold a system in my head, spot the subtly wrong thing — that went up by zero. Review is human-speed and always will be. So the gap between "shipped" and "understood" widens every week, and every project on that list sits a little further past the line where I could reconstruct it from memory. I mark deliberate shortcuts with ponytail: comments now, so future-me knows which corners were cut on purpose. It helps. It isn't enough.

I don't have a bow to put on this. The tooling is astonishing, I'm building things I couldn't have built alone in a decade, and my professional identity is quietly deflating while it happens. All three are true at once.

Everything I make lives at github.com/fgilde, with the live demos and docs collected at fgilde.github.io and gilde.org.

Top comments (0)