Making Good Tech Decisions Without Understanding Technology

Non-technical founders ask this question at almost all TechEye events. How can they hire developers to build a product, if they don’t know what to put in the job specs in the first place?

The same question comes in many forms, maybe you recognize one of them:

  • Should I use WordPress for my website?
  • Which one is better, building native apps in Java/Swift or using React Native?
  • Should I hire a separate backend developer and a frontend person?

And the answer to all of these questions is, and it’s hard to believe, that it doesn’t really matter. When you start out on an MVP, almost everything else is more important than the technology choices.

To make this point super clear: as long as you can build a product that people use, there really are no bad choices.

For sure, some technologies are better than others in a specific way, but bad tech is a problem you can fix later. Indeed, sometimes bad tech decisions can be an expensive problem to fix, but you can almost always fix them.

Not having customers is not a problem you can fix later.

Before making any decision

Before you even think about tech, talk to 10-20 people who might be good customers. Cold call them if you must.

To my own surprise, people will give you money if you solve their problem, even when you don’t have a logo, a company name, or a product. I was a high school student with a home-baked CMS when I started out 18 years ago. I had no idea how to run a business or to build a real product, and yet, people queued up for that service. You can deliver the service without any automation, as long as you solve a problem.

For all the ideas that don’t survive these 10-20 discussions: don’t bother building them. Good tech won’t fix any of the problems you face when you’re working on a bad idea. You can make a bad movie out of a good script, but you can’t make a good move with a bad script. You’ll save a lot of time if you sell first, and build later.

I’m ready! So how do I choose technology?

You don’t choose tech. You choose the developer who chooses tech.

If there was a single tech that’s better than all the others in every possible way, surely everyone used that one. WordPress is great for some websites, and for others you can use React with Gatsby. And sometimes you don’t even need a website.

Developers have heated discussions about their tech. Go to Reddit and observe debates: some get more heated than debates on god and vegetarianism.

It’s not important to tell a good argument from a bad one either. All you want to know is that:

  • The chosen technology stack can be used to solve the problem
  • You can find another developer who can continue the work, in case the first one gets hit by a bus

Choosing tech is therefore a two step process.

  1. Find developers who can build the product, who you trust and can work together with. That determines 90% of the technology choices, because no developer is really good at multiple frameworks.
  2. Try to find another developer for that same thing, and make sure that your main dev would be happy working together with them. If you find it easy to assemble a good team, only then should you proceed.

The best option for you is to avoid originality in any form. If you choose Django/Python/Rails or anything that a lot of people use, then you’ll always have options. Having options matters life or death in situations where a dev team leaves you stranded.

Other than having options and being able to build a product, don’t worry about tech at all.

Whichever tech you end up using, if you can build a team and a product with it, that’s the right tech for you. An average startup rewrites their entire code base every 1-2 years while scaling up. You’ll do well if you can build a business in the meanwhile.


Want more just in time product advise?

  1. Check back later, we’re preparing new posts every week
  2. Sign up for our newsletter!
  3. Come to our next event, or just ask anything now

About

Richard Dancsi

Founder & Techie

Startup founder and management consultant with over 15 years experience in building technology teams, products and companies.