You have this great idea for a startup. It evolves around technology (like most of the innovation nowadays). So, how do we go about when considering building a tech product that would bring our idea to life?
Before we even start considering the technology stack, there is one prerequisite: we need to know the vision for MVP (Minimal Viable Product) behind the idea.
The vision needs to be functional enough (so not totally vague, or fluffy) and clearly get the idea across to potential customer as something useful and valuable. We need a clear goal of the product in order to be able to build it. Some founders will have a complete vision of the product, that they have thought about a lot, and validated by talking with potential customers.
If, as founders, we don’t have a clear vision for the product in its first iteration, then the best thing is to pause — in this case selecting a technology stack for the product is not the right problem to solve. I say ‘in its first iteration’, as we should always embrace evolution and change of our idea, be it based on customer feedback, market metrics, competitor moves. In the first iteration, we are looking for the clear vision, that will guide us in building the MVP (Minimal Viable Product) offering.
If you’re at the stage where you need more time to develop and test the idea for your product, consider using the concepts of the Design Sprint (https://www.thesprintbook.com/) — a time-boxed exercise in designing a product, building a prototype and testing the result with potential users or customers within a week. For more on Design Sprint, and developing your startup ideas, see the Design section of TSF’s blog: https://medium.com/tsftech/tagged/design.
In this piece, we’ll concentrate on the technology selection process — so let’s assume at this stage that we have a clear vision of the product, and what we want to achieve for the MVP release.
Typically, there are two considerations when it comes to startup tech selection:
1. It has to be quick and not too expensive to build, we are a startup after all
2. It needs to have qualities of a good technology product: be easy to change and maintain, efficient and cost-effective to run in production, scalable and performant (when we do get to those one million customers)
These requirements are somewhat conflicting: we can hack something together by hiring teenager next door who is into programming. Or we can find an experienced dev team who will solve the problem in the latest experimental language developed by Nasa.
Or we can (hopefully) be sensible and find a third way — something can be developed quickly and efficiently early on, and won’t compromise on quality or flexibility as the idea and product develop further.
The technology selection will depend on a number of other factors as well, for example: what is the concrete form our tech product will take? Are we building a web application or a mobile app, a SaaS platform or a marketplace, an IOT embedded device or a desktop program? Is it going to be consumer focused with potential for millions of customers, or B2B solution with few hundreds of users at most?
Regardless of what form does the product take, our goal should be to build quality software — how do we choose the tech stack that would enable us to do just that?
Good news is that there are many correct answers. The quality of the software has very low correlation to the technology stack used. I’ve personally seen great software craftsmanship, user-friendly interface and with excellent performance and scalability, written in both NodeJS and Scala or GO, as well is old-school Java and .NET. I’ve seen a lot of bad code in many languages including before mentioned ones.
So, it seems we can use almost any technology to build a very good software product — so, I hear you ask, how do we settle on the one to use.
Let’s go through a few questions we should ask ourselves about the technology we’re considering.
Is anyone else using it?
To pick any technology, the first consideration should be the active community — languages and framework that are used by hundreds of thousands of people across the world, with excellent online resources and a few books to its name — in other words, proven technology with a lot of practitioners.
Consider someone tells you: “There is this great new language X which is the best thing since sliced bread” — you need to make sure that there are not just 5 people in the world who know how to use it, and they cost their weight in gold a day. Be careful, though, not to reject truly innovative technology simply because it’s very early in its lifecycle — it can become a standard of tomorrow, and make a key differentiator of your product if adopted in time.
To evaluate the community, have a look at the main developer hangouts — Stack Overflow, Github, Reddit, Hashnode, etc. and see what are the most popular topics, projects, discussions.
Is there enough talent?
That brings us to the real problem for a tech startup founder — how do I find the right people to build my product using the right technology?
This follows the previous tech community discussion. The community consideration usually matches the state of the market, which is the key reason to take into account — you want technology that fits well with your team. You can solve most problems using any of the many different languages and tools — that is not necessarily true for team selection. If you have a team that you trust already, the technology choices should be made to match the team aspirations and skills. If you’re looking to hire a team, selecting a widely-used, proven tech stack with a vibrant community will make the talent pool much larger.
Another talent acquisition challenge is the balance between pragmatism and perfectionism within the team. How do you choose between hiring pragmatic engineers who will make sure the quality software is built in the most efficient manner, but make sure not to miss on mavericks whose innovation can make a huge difference in the future?
There is no easy way to solve this conundrum — it needs experience and takes time. That’s what brought all of us at tsf.tech together — along the way of our long careers in different industries, we occasionally met people who have the right balance between perfectionism and pragmatism, and eventually (years later) we got to work together and try to help startups solve similar problems. Every now and then, we meet a new person with a similar mindset and try to bring them into the team — which is how we ended up with a small team of pragmatic perfectionists that works together to bring brilliant tech ideas to reality. This is the same approach we use when building teams for the startups we work with — depending on the nature of the startup, resources available and innovation required, we can make sure to assemble a balanced and motivated team ready to take on the problems as they come along.
Technology costs money, right?
Being a startup, we probably don’t have too much money in the bank (and even if we do, we are very careful with how to spend it).
We already mentioned the most expensive part we should consider when building a technology product — human talent. However, technology itself can be costly as well — here are some suggestions for managing that costs.
Most software development languages are free to develop for — after all, it is in the interest of the platform provider to have as many developers using it to build software. That covers the language, but not all libraries and tools we may want to use.
It’s common sense to prefer our talented team to build new and features driven with by the product idea, not re-invent the wheel by building things that have been solved many times before (sending email, process an image or start the server to serve our APIs).
Best thing a startup (or any other tech company) can do is embrace Open Source. Using already existing tools, components and libraries available publicly as Open Source, would save us time and effort; and more importantly it ensures quality — the large community around Open Source will ensure that there are hundreds of developers improving the code all the time, a resource pool no single company could match.
How far the open source has come is illustrated that even banks and other financial institutions, often credited with inventing the NIH Principle (Not Invented Here, where even most common software problems are build from scratch out of concern about security and IP ownership), have been embracing it en-masse, finding a way to work with open source within their legal and security requirements.
One last part when discussing the technology cost, are potential license costs for proprietary supporting software, required for the functioning of the tech product — e.g. databases, messaging middleware, content management systems… There are no hard rules regarding these kinds of components, as what’s required will depend on the nature of the product we’re building.
However, it always makes sense to start from open source versions that cost nothing, and then upgrade to any paid-for versions as required.
Need a database? Start with MongoDB or MariaDB — wait until/if you really need it before considering something like Oracle Database or Microsoft SQL Server.
Is the technology core part of the product?
Typically, the technology is the tool we use to create a medium that helps our customers to consume the product. Sometimes, however, technology is THE core feature of the product or at least key differentiator.
For example, if you’re building software that will integrate with bank systems, the key feature of such software should be security. Without security matching certain standards, there is no product as there won’t be enough trust to use it with sensitive financial systems — so we can’t afford not to use the best-in-class security technologies, even if that means using proprietary technology without the huge community behind it.
Or, as another example, let’s say that a product we’re building is a distributed system that will serve as a critical component for our customers (e.g. the customer will depend on your system to be robust and resilient with 99.99% uptime — like github.com or cloud computing service). The resiliency becomes a key feature of our system, so our technology stack selection must match that accordingly. In that case, we may use Scala and Akka in combination with high availability messaging middleware like Kafka as proven technologies for a system that is asynchronous in nature, resilient and elastic (https://www.reactivemanifesto.org/). Although Scala and Akka have been gaining in popularity in recent years, they are still quite specialist skills, which cost more — but due to the importance of its features to the startup product, considering them as an initial technology of choice would be justified in that case.
How many different technologies do we need?
The technology product will usually consist of many components our team will have to implement — for example, website/mobile app, backend server for REST APIs, number-crunching machine learning component, command-line interface…
In order to build the best quality software, we should use the best tool for each job, right? So, we would build front-end app using react/react-native, backend server using Spring Boot, a data-processing component with Spark and Scala, and add some command-line interface implemented in GO.
The stack I mentioned above is from the first-hand experience and is generally a good specialist technology selection to ensure that each individual component is developed using the best available tools and libraries.
However, using a large set of tech in a product requires a lot of specialist (read expensive) skills and a medium-to-large team.
Therefore, the detailed specialisation may not be the best option for an early stage startup.
Using tech stack that can be used for a broader set of components would be advantageous. Let’s have a look at one concrete example.
A Concrete Example
Let’s discuss some concrete options at this stage: Javascript is the first language that pops to mind — proven, easy to start with, rich ecosystem and definitely one of the most active communities in the wild web — what’s not to like. You can spin up a rest API server in no time (using NodeJS), write quick scripts or large projects. Easy to build, run locally or on the cloud as you wish.
Javascript is a de-facto language of choice for front-end development, with a huge choice of libraries and frameworks for building browser-based HTML apps — React, Angular, Vue…to name just a few.
Javascript can be a great choice to build a mobile app as well — see React Native as one of the most popular. Another option is to write the front end code just once and have it run in the browser on either desktop or mobile (build-once-run-anywhere).
Having the ability to use the same stack across the technology estate has big benefits in sharing work and knowledge, and being able to build truly cross-functional teams.
Flexibility — what if I need to pivot?
One sure thing from building a startup technology product is that, sooner or later, we will need to change direction, evolve approach or even perform a full-blown pivot. The reason to make the significant change to your product could be based on the user feedback, latest market research, regulatory change, move by the potential competitor.
Making a software flexible to changes in requirements, so it’s easy to support and maintain, typically has nothing to do with the actual technology stack — it’s the architecture and design of the software and development best practices that are the main drivers of flexibility.
This is a broader subject, worthy of a separate blog post. In short, if you: I) make sure that software product has a modular design, with clear dependencies between components; ii) interaction between components is contract-driven (so we can replace a component with the new one, as long as the new component fulfils the same defined contract). And iii) ensure that the software is fully tested so that any regressions due to new features or requirements can be tested and caught as early as possible.
The change does not have to be driven by functional requirements. Production and operational flexibility should key drivers when you consider the technology stack selection.
Operational Flexibility
You may want to move to another cloud provider in order to cut cost. Or, after a successful marketing campaign, you have to be able to serve significantly more customers than before. In either of these situations, you don’t want to have to rewrite the application to achieve any of the non-functional goals.
So, don’t tie your tech product to a particular cloud provider too tightly.
And make sure any scalability in the increase to traffic can be achieved without changing the code of your application.
To achieve this, we suggest making your software product containerized. You can think of containers as of next-gen virtual machines (VMs). Using containers, your application can be split into isolated deployable modules that can run on any Linux-based operating system — be it on developer’s laptop, physical server, VM or in the cloud.
Containers have become so ubiquitous, that we now have standardised way to deploy and manage container-based services on any cloud, using container-orchestration services. One of the most popular such services is Kubernetes, developed originally by Google, but now supported by all major cloud providers.
What this means is that, if you use containers as packaging and deployment mechanism for your application, you can easily switch between cloud providers without rewriting most of your code.
And with container orchestration software, scaling your container-based application horizontally becomes as trivial as running a command
The de-facto standard container technology is Docker, an open source container software. It provides a set of development tools which makes it easy to create and run docker containers on a developer’s laptop, and is supported by main container orchestration platforms, including Kubernetes.
This adds another benefit — now the development team can run the application locally using the same tech stack that’s used in production. Closing the gap between the local development environment and the production environment means that we can test and validate our software in a production-like environment very early in the development cycle, by using developer’s workstation only, shortening the development feedback cycle and shipping better-tested software.
Conclusion
“Do Something Great neon sign” by Clark Tibbs on Unsplash
The key aspect of a successful startup is clear and coherent idea for a valuable product. Building it should be easy, right? Well, yes and no. We argued that the quality technology product can be built using many different technologies. However, selecting the right one(s) is key to have the product built efficiently, on time and budget, without sacrificing innovation and flexibility on our way to millions of customers and world domination.
The technology needs to match the team, so one of the key consideration when selecting the technology needs to be the availability of talent and the rich community ecosystem that fosters knowledge sharing the innovation.
Using open source technology will contribute to keeping the focus on the development of the specific problems at hand, by using well-established tools of libraries that solve the common technical problems, with the added bonus of being free.
The flexibility of the selected technologies should not be disregarded — both functional flexibility (changing the direction/requirements of the product), and operational flexibility (ability to switch infrastructure to lower cost and scalability to respond to extra demand in the most efficient way)
Finally, special attention should be made for technologies that are key features of our product themselves or act as key differentiators — in that case, functional suitability should be the main driver during the selection process.
Using these principles at TSF.tech, we have built a number of products using different technologies — many using Javascript and NodeJS, with some Scala/Akka and Go and even Java and .NET where it made sense. Throw containers in the mix, mainly Docker with Kubernetes or Heroku, and we are equipped to start solving most of the problems thrown our way.
But we do make sure we are always open to new and innovative tech — because the next big thing in technology can be just around the corner…
