The bar went up
The bar for tolerable software has gone up. Not delightful—tolerable. If your product is confusing or half-baked in the ways that matter to me, why would I spend a single second in your ecosystem, clicking around clunky tools? If I can’t find the information I need, if a feature is confusing, if the page loads too slowly, if you’re not anticipating my needs and helping me do the jobs I want done more quickly, efficiently, and frictionlessly—what’s the incentive to stay? Give me a decent MCP and I’ll let my good friend Claudinho figure it out. That’s the real risk of shipping slop.
Invisible and visible at the same time
There are a few products I genuinely love using day to day because they’re so good they’re invisible. But they’re also incredibly visible in the ways that make you feel the craft, thoughtfulness, and intentionality behind every decision. That’s how I know I’m in good hands as a user. It makes me want to give my time and money to the people building the products I want to use.
You need both worlds
Products today need both: an amazing headless experience for agents, and a beautiful, well-crafted product experience that makes humans want to stick around. That means there will always be a market for thoughtful, well-crafted, intentional software in any vertical—no matter how jarring it feels to see everyone talk about building anything with Fable in a day. Yes, you can vibe-code versions of multiple apps. But most of the time, paying that $8/mo is worth the peace of mind of not having to maintain your crappy vibe-coded version. Congratulations: you’ve created another product roadmap for yourself. Compare that to having a dedicated team whose sole focus is to ship the most delightful version of the product you want to replace with a weekend project. If they truly live and breathe the problem space, and have the talent and resources to deliver an amazing product, you’re in luck. And if they don’t really care that much, they’re screwed anyway—because life is too short to use shitty software.
A feature is not a Product
It’s easy to fall into the trap of “why build this thing? I saw someone vibe code it on the timeline.” That thinking is misguided because you’re framing the thing as a feature rather than a Product with a capital P. There’s so much more to a Product than the UI or the functionality under the hood. It’s how things are packaged together, how it fits into a story, how the experience of using it feels, how it speaks to a customer, how it helps you acquire them, how it feels as a whole rather than a singular thing you can point to and dismiss as “easy to vibe code.” Packaging is the invisible thing. Once you experience it, you can’t unsee it.
The vocabulary is a virus
The vocabulary around this shift has become its own tell. I’ve never heard engineers use the terms “gates,” “smells,” and “lands” as much as I have over the last couple of years. Claudese is a virus infecting our collective vocabulary. It must be eradicated.
Trust your process
And none of the good stuff—the packaging, the feel, the Product with a capital P—comes from rushing. It comes from trusting your instincts as a creative: giving yourself permission to play, explore, scrap your ideas, try again, get lost, keep trying, and ultimately know that you’ll arrive at the right solution, at the right time, without rushing your process.
The new bar
That’s the bar now. Not just software that works. Software that respects your time, anticipates your needs, disappears when it should, and shows its craft when it matters. Anything less is slop. And life is too short for slop.