Hacker News new | past | comments | ask | show | jobs | submit
This argument always feels like a motte and bailey to me. Users don't literally care what what tech is used to build a product. Of course not, why would they?

But that's not how the argument is used in practice. In practice this argument is used to justify bloated apps, bad engineering, and corner-cutting. When people say “users don’t care about your tech stack,” what they really mean is that product quality doesn’t matter.

Yesterday File Pilot (no affiliation) hit the HN frontpage. File Pilot is written from scratch and it has a ton of functionality packed in a 1.8mb download. As somebody on Twitter pointed out, a debug build of "hello world!" in Rust clocks in at 3.7mb. (No shade on Rust)

Users don't care what language or libraries you use. Users care only about functionality, right? But guess what? These two things are not independent. If you want to make something that starts instantly you can't use electron or java. You can't use bloated libraries. Because users do notice. All else equal users will absolutely choose the zippiest products.

loading story #43128427
>When people say “users don’t care about your tech stack,” what they really mean is that product quality doesn’t matter.

No, it means that product quality is all that matters. The users don't care how you make it work, only that it works how they want it to.

I have never seen it used like that. I have always seen it used like parent said: to justify awful technical choices which hurt the user.

I have written performant high quality products in weird tech stacks where performance can be s bit tricky to get: Ruby, PL/PgSQL, Perl, etc. But it was done by a team who cared a lot about technology and their tech stack. Otherwise it would not have been possible to do.

This is a genuinely fascinating difference in perception to me. I don't remember ever hearing it used in the way you have. I've always heard it used to point out that devs often give more focus on what tools they use than they do on what actually matters to their customers.
There are developers who care about tech and not about product. They build toys.

There are developers who care about product and not about tech. They build things that just barely work.

There are developers who care about both. They build the stuff people remember.

I have often heard it used to create a (false) impression that the choice of tools does not affect things that matter to customers - effectively silencing valid concerns about the consequences of a particular technical choice. It is often framed in the way you suggest, but the actual context and the intended effect of the phrase are very different from that framing.
TFA uses the phase that way.

> What truly makes a difference for users is your attention to the product and their needs.

> Learn to distinguish between tech choices that are interesting to you and those that are genuinely valuable for your product and your users.

Would like to echo this. I've seen this used to justify extracting more value from the user rather than spending time doing things that you can't ship next week with a marketing announcement.
I've also seen it used when discussing solutions that aren't stack pure (for instance, whether to stick with the ORM or write a more performant pure SQL version that uses database-engine specific features)
> I have never seen it used like that.

Then you need to read more, because that's what it means. The tech stack doesn't matter. Only the quality of the product. That quality is defined by the user. Not you. Not your opinion. Not your belief. But the user of the product.

> which hurt the user.

This will self correct.

Horrible tech choices have lead to world class products that people love and cherish. The perfect tech choices have lead to things people laugh at and serve as a reminder that the tech stack doesn't matter, and in fact, may be a red flag.

Look at every single discussion about Electron ;)

"It's a basic tool that sits hidden in my tray 99.9% of the time and it should not use 500MB of memory when it's not doing anything" is part of product quality.

loading story #43126714
loading story #43127749
Businesses need to learn that, like it or not, code quality and architecture quality is a part of product quality

You can have a super great product that makes a ton of money right now that has such poor build quality that you become too calcified to improve in a reasonable amount of time

This is why startups can outcompete incumbents sometimes

Suddenly there's a market shift and a startup can actually build your entire product and the new competitive edge in less time than it takes you to add just the new competitive edge, because your code and architecture has atrophied to the point it takes longer to update it than it would to rebuild from scratch

Maybe this isn't as common as I think, I don't know. But I am pretty sure it does happen

loading story #43135395
> No, it means that product quality is all that matters

But it says that in such a roundabout way that non technical people use it as an argument for MBAs to dictate technical decisions in the name of moving fast and breaking things.

loading story #43128785
> product quality is all that matters

I don't know what technology was used to build the audio mixer that I got from Temu. I do know that it's a massive pile of garbage because I can hear it when I plug it in. The tech stack IS the product quality.

I don't think that's broadly true. The unfortunate truth about our profession is that there is no floor to how bad code can be while yet generating billions of dollars.
loading story #43135613
For 99% of users, what you describe really isn't something they know or care about.
loading story #43135587
If users care so much about product quality why is everyone using the most shitty software ever produced — such as Teams?
As far as I can tell the article has been misinterpreted causing much lost hours by HN commenters. By saying users don't care about your tech stack, it is saying you should care about your tech stack, i.e it matters, presenting some bullet points on what to keep in mind when caring about your tech stack. Or to summarize, be methodological, not hype-following.

Agree the article is not clearly presented but it's crazy to see the gigantic threads here that seem to be based on a misunderstanding.

I feel like that's what it should mean, that quality is all that matters. But it's often used to excuse poor quality as well. Basically if you skinner box your app hard enough, you can get away with lower quality.
Yes, this is exactly what the article means.
"Use whatever technologies you know well and enjoy using" != "Use the tech stack that produces the highest quality product".
loading story #43128084
loading story #43127013
loading story #43128487
loading story #43128005
loading story #43127839
loading story #43127989
loading story #43127079
loading story #43128559
loading story #43127049
loading story #43128123
loading story #43130134
loading story #43127371
loading story #43132328
loading story #43127378
loading story #43136724
loading story #43127018
loading story #43128177
loading story #43130784
Love this reply and learned a new term from it.
loading story #43131634
loading story #43127817
loading story #43126473
loading story #43130971
loading story #43126515
loading story #43126469