You built a web app. You needed a spreadsheet.
The new failure mode isn't bad code. It's building the wrong thing with extraordinary confidence.
Someone told me last week that they’d built a web app for their team. Full frontend, database, authentication, deployed. They were proud, and honestly they should be. Shipping something real is a rush, and they’d done it in a day.
The workflow serves seven people. The data is tabular. The core logic is: if column B exceeds a threshold, flag the row. This is a Google Sheet with a bound AppScript. Maybe 40 lines.
They didn’t know that, because they’d never had to think about it before. The AI said “sure, I can build that,” and it did.
This is a different problem than what I wrote about before
In February I published “The blueprint paradox,” about how documentation-first building beats vibe prompting. The data was clear: projects with upfront decisions shipped at 123 lines of conversation per commit. Projects without them cost 362. Same developer, same tool, same month. That argument was about how you build with AI.
This is about whether you should build at all.
The vibe coding discourse has mostly been engineers arguing about code quality, architecture, technical debt. Valid concerns. But the failure mode I keep seeing now isn’t bad code. It’s perfectly functional software that shouldn’t exist. The seven-user workflow that needed a formula, not a deployment pipeline. The internal dashboard that could have been a Notion database. The “app” that’s really a spreadsheet with extra steps and a hosting bill.
Just because you can build it does not mean you should. And just because it looks nicer as a web app doesn’t make it the right form factor. A Google Form would do. A shared Sheet would do. The product decision isn’t “what can I build?” It’s “what’s the simplest thing that solves this, that I won’t have to maintain?”
We’ve seen this before
The web was made publicly available in 1993. By 1996, personal websites were everywhere. Everyone was writing HTML, learning JavaScript, hand-crafting their corner of the internet. It felt democratic and exciting and genuinely new.
Then blogging platforms appeared: Blogger, WordPress, LiveJournal. The barrier dropped further. Millions of people started blogs. The tools got better, the hosting got cheaper, and for a few years it seemed like everyone was publishing.
How many of those blogs survive today?
Not the platforms. The individual blogs. The personal sites. The hand-rolled HTML pages. Almost none. Not because the content was bad (some of it was great). Because maintenance is a separate skill from creation, and nobody signs up for the maintenance when they’re riding the high of the first deploy.
Vibe coding is the 2026 version of the 1996 personal website. The tools are better. The output is more impressive. The excitement is real. And in three years, there will be a graveyard of unmaintained web apps that should have been spreadsheets.
The engineering philosophy we actually follow
At Glacis, we have an explicit rule in our engineering philosophy: the 20/2 trade-off. If a requested feature offers a 2% functional improvement but increases codebase complexity by 20%, we don’t build it. We build for current requirements. No generic engines for hypothetical future use cases. YAGNI isn’t a suggestion, it’s a design principle.
Our complexity check, the one we enforce on every piece of code, is a single question: “Is this the simplest way to write this for a human to read?” If you’re creating an abstract base class, a factory, or a generic interface that nobody asked for, stop. If you’re splitting logic into multiple files “just to be clean,” stop. Prefer long, readable functions over chains of small, fragmented calls.
This philosophy exists because we’ve seen what happens without it. AI-assisted development makes it trivially easy to build complex things. The discipline is knowing when complexity isn’t warranted. A seven-user workflow with one conditional rule doesn’t need a React frontend. It doesn’t need a database. It doesn’t need auth. It needs a Sheet and a formula.
The idea of AI was to do things on existing scaffolds, faster. Not to build something entirely new because you can. You don’t need Supabase when you have 100 records in a single table. You don’t need a deployment pipeline when your audience is seven people who already have Google Workspace.
The sentence that gives it away
“I shipped something my engineering team couldn’t do in weeks.”
I’ve heard this from at least four non-technical people in the last two months. It’s always delivered with a specific energy: vindication. They’ve been asking engineering for this thing, and engineering kept deprioritizing it, and now they built it themselves.
What they’re actually describing is one of two things. Either: the problem had genuine complexity their prototype doesn’t account for, and they’ll discover that when it matters most. Or: their engineering team correctly identified that this didn’t need to be built as software, and chose not to say that out loud because telling a stakeholder “this is a spreadsheet” is politically expensive.
I ran a product team when I was bootstrapped as an individual contributor and then at a $1B tech startup in both IC and leadership roles . I know both dynamics well. The second one is more common than anyone admits. Engineers routinely build things they know are overengineered because the political cost of saying “you don’t need an app” exceeds the engineering cost of just building the app. AI tools didn’t change that dynamic. They just moved the overengineering from the engineering team to the stakeholder’s laptop.
What the non-technical builder doesn’t see
A spreadsheet is zero maintenance. Your team already knows it. It has built-in version history, real-time collaboration, and survives someone’s laptop dying. The web app you built in a day has a deployment, a domain, a database, authentication tokens, session management, and every one of those is a thing that can break independently.
Who hosts it? Who patches the dependency with the security vulnerability next month? Who migrates the data when the schema needs to change? Who debugs it at 2am when the database fills up? If the answer to all of these is blank, you’ve built a demo that people now depend on.
The cost of building dropped to near-zero. The cost of maintaining didn’t. And now there are more things to maintain, built by people who don’t know what maintenance means, running in production because they looked good in the demo.