Yes, please, antagonize technical expertise! When shit hits the fan, it makes us look better.

It's one thing to advocate not over-engineering your minimum viable product, but it's quite another to normalize releasing Potemkin village products and hoping customers pay before they realize the product doesn't work.

If you're the technical expert and you have zero customers, you're in position to win any customer who values technology most of all. You may not even need persuasive sales efforts, mere exposure alone might get the ball rolling.

OTOH, if you're the persuasive sales expert you'll always be so loaded down with customers that you never have time to cater to the most technically demanding ones. Leaving those customers as low-hanging fruit for the top technologists instead.

If it's a technology company, the only time everybody really wins is when you're both.

> A friend sent me this screenshot the other day - his backend had been running for 7 days without a proper database setup. Just failsafes returning empty responses. Any technical expert would tear this apart immediately. (We're talking about a

> But people were using it daily and paying for it.

Assuming this was something customers cared about, it's called "burning the reputation". Yes, it can be quite profitable - ask Broadcom. But it is usually done _after_ the company is famous and has tons of customers, not before.

A good engineer is not a perfectionist, but they're not callous either. It's knowing when to make the trade-off, or at least making an informed guess.

We should really price / punish "oopsies" higher. I don't think any other profession gets away with as much consistently fucking up as software.

Imagine an airline running these principles- who cares if we have a few crashes, as long as customers still pay!

We do have a salary, though. Still waiting to be left behind. Enjoying the rat race? Seems like it.

This should be called the carnival model of engineering

- Build something that is total dogshit but just good enough not to totally fall apart

- Convince people to pay you for it

- Close up shop and split after you've got all their money but before everything falls apart (or at least before people get wise and stop paying)

- Rinse, repeat

Respect, sometimes we forget that our software is actually supposed to do stuff. Will say though you can have both, especially now with llms where you don’t have to trim each piece of wood yourself. Also, it’s not always about cutting corners to make a buck, sometimes it really is about creating a great product that people love using. Engineering quality is part of that.

The author has a qualified point in that it's OK if some part of the app not central to the primary value proposition is not working.

But if a vibe-coded app promises to solve a problem for a paying customer and does not actually solve it but leads the customer to believe that it is being solved, that is fraud.

What a terrible article. The author throws completely different types of problems into one pot, regardless of whether they have real User-Impact, cause Potential Security problems or Data loss or are just architectural decision with no user-impact at all. And then continues to apply the same logic and argument to all of them - that the users are wrong and should just shut up.

I truly hope he never becomes a product manager anywhere I am a customer.

This stops short of smirking at the users who continue to pay because they are ignorant of just how shitty the software system they are using is. Until everything blows up with the inevitable data breach or data loss incident that is.

I like this take (with or without the AI bit). A lot of time crude crap doesn't pass muster in theory but holds up in practice.