When it comes to tech choices in a startup, there are a few big things that we need to be thinking about.
An obvious one would be deciding what programming language to use. Over the years, there has been a trend to use the best tool for the job. This means you can use many different languages for different bits—for example, one for the web-front-end, one for the app, one for this micro service, another for that microservice, one database here and another there.
If you are a non-tech entrepreneur and you go to a software house to help develop your product, they will usually make the language and tech choices for you, and they often choose what is best for them, the tech that they always use because they know it. On the plus side choosing what they know allows them to deliver your product quickly, but on the downside it might not be the best option for your startup in the long run. Are they using outdated tech? Are they using obscure tech? Are they using overcomplicated tech? You will have to live with the consequences of their decision, so you had better know.
One language fits all
However, in the startup world, when we are looking to deliver quickly, on a budget, to prove the product-market fit, having one core language that can be used for everything is our preferred option. It reduces the complexity of your product by keeping the amount of knowledge required to run it manageable.
A lot of the time, the language itself isn’t all that important. Mostly, you could build in any language because the thing you are designing isn’t particularly specialised in any way. Sometimes it’s just simple stuff like a website or an app, and that can be done reasonably well in any language. So the only real reason for choosing a language should be based on who is available to build what you need building, who can extend and support it, and how much they cost.
Mainstream languages – pros and cons
In many cases, your team may be composed of younger, cheaper developers like recent graduates who will need to pick up the language and run with it, so having something more mainstream is useful, and less expensive.
If you had some deep eternal love for a complicated, non-mainstream language like Haskell (I’m a lover not a hater), it would be practically impossible to find any cheap developers to help you out. Remember, for startups it’s about getting your idea and turning it into a reality so in most cases using the more mainstream languages like JavaScript stack, for instance, is a good place to start. There are times where you may need to switch to something more specialised. For instance, if you are building something that includes a lot of AI, you may want to switch some of your stack to something like Python because it has more AI libraries.
Mobile tech choices and cross-platform development
Sometimes you may not have the luxury of just picking one language and using it for everything. Mobile application development is a good example with main players like Apple and Google having separate platforms using two completely different languages.
In this case, if you want to build something across the board, you need to have a much wider range of skills and take different approaches to solve problems which become much more challenging. This is where things like cross-platform mobile development come into play with the community coming together and trying to bridge the gap. By building libraries or frameworks that allow a single code base to be used, we now can use cross-platform tools like React Native to use JavaScript on the front-end.
These open-source frameworks have made it easier for startups to keep it simple, pick a single mainstream language and find the relevant people to build what they need, which is massively important.
Open-source libraries
When I talk about open source essentially what I mean is code and libraries that are published and shared so that everyones can use them, generally for free. These days even in the simplest applications there are so many moving parts that creating it all yourself would be like forging your own steel, bending it into wires and then putting up a fence! You would never get anything done.
But there are some considerations to be made here too. Picking tools that are available and free is great, but make sure you are picking tools that have a good community behind them, not just one guy.
Ultimately, the decision of what open-source tools to use, or whether you use them, is an easy one to make. I wouldn’t be scared of picking a piece of open-source code and using it now because it might change in the future. The reality is everything changes and you’re always going to have to respond. Besides, the alternative to not picking open-source code and doing it yourself can be worse.
It will take far longer to create your own code, and you’re still going to have to change it in the future to keep up with the world. Having done both before, it’s no problem picking something up and changing it down the line. You will have saved yourself a bunch of time and perhaps have got yourself a year’s worth of work for far lower input.
Don’t just consume – create
Sometimes, as an engineer, your job is to pick those little parts that solve part of your problem and compose them into your own solution. But solving problems this way can be a challenge for engineers’ motivation. It can be a boring job just sticking pieces of open-source code together like a jigsaw puzzle rather than inventing something new, but that’s where creating in open-source code, rather than just consuming it, can give that motivation back.
Allowing your employees to release and maintain their own open-source solutions that support your startup and work on these on company time. This will enable them to create some really great low-level code which can also function as a marketing piece for you. A great example of this is our good friends over at Invertase who have built a React Native Firebase library which is now supported by Google.
The challenges of open source
However, as great as open source is, it does create problems. A lot of times, we treat open-source software as black boxes without really understanding what’s happening inside. We just jump straight in and get bitten by challenges down the line when we discover that the implementation is doing something very specific that we haven’t accounted for.
Also, because there were so many ways of putting different things together to achieve something, what is the right way of putting it together? What things do you even need to search for? The open-source way of doing things is like using Lego blocks. Each one is a small little piece that does a specific thing, and this means you need to collect lots of them and put it all together rather than using one big library.
It can be a hard learning curve too. The bigger these libraries are, the harder they are to learn, and the more likely you are to discard them before overcoming the initial barrier to entry.
Be consistent and take ownership
So, when it comes to tech choices, you should try to look at consistency. Try to use as few moving parts as possible and look for a single language you can use across the board. It will make your life much easier in the short and medium-term when you hire your team and prove your market fit.
But you don’t want just to let these decisions happen by accident and then live with the consequences. If you’re the founder you need to take a little bit of ownership in it and direct to where you want to go, not just because it’s what suppliers want or because it sounds like the next cool technology.
I hope you have found this useful. If you have any questions or would like to hear more about making the right tech choices, check out episode 8 of our podcast, “From the Factory Floor” where we go into more detail. Alternatively feel free to email me at ericc@thestartupfactory.tech
