Recently I had a chance to meet and talk with several aspiring entrepreneurs. They all had different business ideas but our conversations eventually converged on one common problem they had: they didn’t have enough knowledge to make an informed decision on which technology to use to build software, and were feeling helpless. That lack of knowledge also led them to form some potentially harmful misunderstandings about software technology.

This post is a summary of the advice I gave them. It aims at dispelling some misunderstandings commonly held by entrepreneurs with no software background.

This post assumes a few things:

1. You’re building a standard mobile/web application. If you’re building something different like embedded software integrated with hardware, some of this advice doesn’t apply to you.

2. You’ve done some basic research, enough to have cursory understanding of the jargons thrown around in this field but to be still baffled by them. I mean terms like HTML, CSS, JavaScript, frontend/backend, native/hybrid application, and so on. I want to help you organize those fragments of technical knowledge in a coherent business context, but for obtaining basic knowledge, there’s a far better teacher than I - it’s called google.

Let me start by explaining what a technology stack is. It’s a jargon that’s generally used to describe a combination of software products and programming languages used to create a software. It includes programming language, database, development framework, and pretty much all the tools and parts someone would consider as “technical stuff.” It is the term I will use in this post to refer to all the technical stuff.

Worry about tech stack after your idea survives its first contact with customers

This is the most critical problem I see over and over. If your business is about selling wooden desks, the most important thing is to find out what kind of desks are valued by potential customers. Instead of worrying whether mahogany or cypress would be better, go ask around what customers want. Make sample products for testing if you need to. Your decision on which material to use should be made after you find out what kind of desk do customers actually want.

This is called finding the product/market fit. This basic business principle applies the same way when your main vehicle of service or product is a software. So stop worrying prematurely about tech stack unless your business actually depends on a particular tech stack. And if you’re reading an article like this, it probably doesn’t.

You shouldn’t focus on a particular tech stack, but on what qualities it has

I believe that a tech stack for startups requires these characteristics:

• High productivity
  It allows developers to write valuable software quickly. Maintainability is still important, but being able to quickly produce minimum viable product is much heavily emphasized.
• Good enough reliability
  It can be generally trusted to work well. Although there could still be some edge cases, most common bugs and security issues have been already addressed.
• Developer availability
  It should be possible to hire additional or replacement developers when required.
• Community support
  There are people who can answer questions about that language or framework, but it doesn’t require dedicated teams of professional technical support.

In other words, it should allow you to build your product quickly with as little obstruction as possible. As of October 2016, there are four popular programming languages for startup mobile/web application. In the format of programming language/most popular development framework pair, they are:

• JavaScript/Node.js
• Ruby/Ruby on Rails
• Python/Django
• PHP/Laravel.

There are other language/framework pairs too, but startups tend to stick to those four. Other tech stacks are less appropriate for startups because they have low productivity (e.g. C#/.NET, Java/Spring), are too new (e.g. Elixir/Phoenix, Swift/Vapor), or too exotic (e.g. Haskell/Yesod).

At this point, your question would be this: which one is the best among the four? Technically, it depends on what you want to do. Each has strengths and weaknesses. Practically, they are all good enough for your needs.

You are fine as long as you choose one of them, or any other stack that has those qualities. Remember that it’s not about a particular tech stack. It’s about those qualities. Trust in your CTO and delegate specific choices to him or her.

Oh, and scaling. Some people worry whether their software would be able to scale in the future. What do you think of a new entrepreneur, who has not even built the first prototype of her product to test the market but tells you that she is worried whether she would be able to have production capabilities to meet all the demands from future global operations of her business? That’s how you sound when you worry about future scaling, so please stop doing that. Instead, spend your energy worrying about making the product-market fit and revenue, not daydreaming about scaling until you actually need it.

Your tech stack also affects other areas of your business like hiring

I’ve been reminding you that tech stack is just one of many parts that make up your business, and that its specific configuration does not mean much to you. You have a bigger picture to draw. For developers, however, tech stack means a world to them.

How does this affect you as a head of company? The main implication is that your choice of tech stack affects both the size and characteristics of your hiring pool. It’s obvious that the older and more mature a technology is, the larger its hiring pool is.

What’s less obvious is that different tech stacks attract different kinds of developers. In general, the newer and trendier technology, the more passionate and adventurous are those attracted to it. Or in a less positive tone, it attracts only those who are crazy enough to leave familiar technologies behind and dive into uncharted territories of new technology. Of course such developers are more of an exception rather than the norm, just like the rest of human population, resulting in a smaller hiring pool.

Notice that I am careful not to imply either pool has more skilled developers, because it’s not that simple. Older and more mature technology has much larger sample size, thereby increasing the sheer number of skilled individuals. They also had more years to hone their expertise in that particular technology. On the other hand, newer and trendier technology has higher concentration of inquisitive minds, one of the key qualities of a skilled developer. It ultimately comes down to whom you end up hiring, and that’d require another long post to talk about so I won’t go into detail here.

Tech stack signals your expectations about developers, and their expectations about you

Let’s get back to the tech stack. So your choice of tech stack also signals that you’re looking for certain personal characteristics in your developers. At least that’s how software developers interpret such signals.

In response, they form certain expectations about your company. It’s more psychological than technical, like how you form a quick first impression of another person based on his clothes, gestures, way of speech, and so on. Companies that use new trendy technologies are associated with cool jobs, fast-paced and flexible work environment, personal growth, but also with financially instability.

That leads to another implication of tech stack, namely its cultural baggage. When your company’s organization and culture does not satisfy expectations associated with certain technology, those developers will become disillusioned and unhappy. Well, except for financial instability part. Nobody likes that.

It’s almost impossible to specifically pin down which tech stack is considered new or trendy, or what kind of expectation comes along with a technology. That’s like trying to pin down fashion trends for this autumn. The best way to figure it out is by continuously communicating with other developers and, surprise, surprise, diligently following technology trends just like you follow fashion trends.

Good luck with it!

In summary: focus on your job as a head of a company to find the product/market fit, trust in your CTO and delegate away detailed technical decisions, and be mindful of how your tech stack can affect other areas like HR or organizational culture. That’s a lot to do, right? Unfortunately it’s what your position as a head of company entails, so there’s no way out of that. Good luck with it, and thank you for reading this rather long article.