Your Technology Choices Are Irrelevant to Your Users

I’ve seen a lot of people focus completely on a technical aspect of the product. They obsess over every bit of code, over performance bottlenecks they might have (in a distant future), over framework choices and over potential problems with scalability.

Sometimes they waste hundreds of hours to create a perfect architecture, a bulletproof system that can easily be extended, changed and flipped on its head.

This seems very important, but it really isn’t. At least not in the start. People will not look into technical details of your product as long as it’s easy to use and as long as it works as it should. Which language, framework, programming pattern or CMS you use is not their concern. And neither it should be.

Users don’t care about your technology choices. Maybe you shouldn’t either.

4 Inspiring Comments

  1. Users don’t care about the developer’s technology choices but the latter definitely should.

    Simply because users can’t have a look at the code doesn’t give the developer a reason to push bad code live.

    1. Thanks for the comment, Hugo. Indeed, developers have to care about code quality, but they shouldn’t obsess over it too much, at least not in the early stages of the product development. If writing high quality code that isn’t performing significantly better takes triple amount of time, then it may be smart to consider if it’s actually worth it.

      My point here is to ship early and often. It’s useless to worry about top-notch quality code too much before you actually have a product that works.

      Now that I think about it, this post didn’t came out exactly as I intended.

  2. Hm, but if you don’t write quality code from the beginning, then there is no quality in that product. And that is bad.

    But I see what you actually meant, to release as soon as possible, no matter how many features there are developed. Right?

    1. It’s better to have a no-quality product than to have no product at all. Quality is not the point of this piece, the use of quality as an excuse for procrastination is.

      Exactly, ship as fast as you can. Focusing on quality too early may be pointless. If you start working on a product and you realize a couple of months in that the architecture is wrong, it’s much smarter to ship with wrong architecture than it is to change everything, or start from scratch. Ship. If it gains audience, you can change the architecture.

      But don’t get me wrong, there’s no point in shipping something that doesn’t work at all.

Share Your Insight