What is the best Tech Stack for my Startup in 2021? Software Architecture Series, Part II

In the previous part of this weekly series, Architecting London’s Premier HealthTech at Home Provider: Part I, we’ve explored the results of our work. Achieving over 15,000 customers and an excellent rating on TrustPilot, within a bit over six months since launch.

Every week we will be exploring a part of our technical journey at CHT and the steps we’ve taken to both launch and grow at an exceptional rate.

What is the best stack/language for my startup?

At first, it seems like a pretty innocent question. Some engineers might jump ahead and call Django or Python the best choice. Others will strongly defend a different one, ranging anywhere from Ruby to PHP, JavaScript to even Go and Rust. Throw in some Haskell for good measure.

What experience has taught me, in over ten years working with young, fast-growing startups is that there is no right answer to this question. At the end of the day, environments which value language purity over fast deliveries often tie their own hands behind their backs.

The best language you can choose is the one that your existing engineers are most fluent in already. For some, it might seem quite controversial to architect a system based on your staff’s skills, rather than re-skill your engineers in a seemingly better choice.

Without a doubt, a senior JavaScript engineer will, in good time, learn to work proficiently within a Python or Go codebase, or the other way around. However, you have to consider if the reduced output from the re-skilled engineer would not cause more harm than good, especially with tight deadlines.

Technical leads, as well as developers, can often spend too much time designing and building a seemingly perfect technical solution. What often gets lost in translation, from business stakeholders to engineers, is the authentic sense of urgency most startups possess.

Looking at CHT, Covid Home Test, we’ve launched and achieved an exponential growth of over 15,000 customers in around half a year. While the technology behind the platform is impressive, it can always be improved with enough time and resources.

As a thought exercise, if CHT would have spent six months in development alone, a somewhat normal timeframe for most startups to launch their MVP, we would have lost over 15,000 orders to other faster-moving competitors. Unfortunately, this is a path many startups embark on, spending too much time creating solutions, but too little time assessing their viability in the real world.

Our focus, from day one, has not been to build the perfect technical setup, but rather a solid one that we can iterate on. We’ve used certain hosted solutions with extensive industry expertise and filled the gaps between our bespoke services with customized software.

The result, inevitably, is a powerful distributed software engineering effort, combining the expertise of engineers from Python, JavaScript and Ruby backgrounds. Each of these languages takes a front-row seat in our multi-system coordination, handling a vast network of compact, optimised microservices.

Designing any software, especially in a greenfield project seems like a dream for many software leads. In reality, however, these are the most dangerous kind of projects, where the balance between time to market and perceived engineering excellence can become too skewed towards the latter.

Across my career, I’ve been an advocate of designing software with time to market in mind. Young companies depend on their ability to both prove themselves in a highly competitive market and acquire customers at a breathtaking pace.

Every single week of delay in launching the company’s core product has a snowball effect in lost sales, traction and revenue. This can be the difference between a startup leading in its field, or being a distant second.

In short, the best Tech Stack you can choose for a business is the one that gives you results the fastest, with the engineers you already have. Launch as fast as you possibly can and then iterate on the work, rather than prematurely optimise an unproven idea.

Of course, this approach has to come with sensible judgments. You want to take advantage of each language in your arsenal. While a massively concurrent system would be a bit of a stretch for Python, you can simply separate those parts of the architecture for specially designed languages, while maintaining the core logic in more familiar stacks.

Next week, we’ll cover how to design safe, powerful and distributed microservices, including CI/CD pipelines deeply integrated with the flow of each developer.

Learn more about Covid Home Test

Previous Post: Architecting London’s Premier HealthTech at Home Provider: Part I

Do you want to join one of London’s fastest-growing HealthTech businesses? We are looking for brilliant engineers, fluent in Python and JavaScript. See our open jobs portal.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Narcis M. PAP

Narcis M. PAP

Software Architect with 10Y+ Experience. Working with Fast-Growing, Fast-Paced businesses building world-class digital products @ ikigai.net