Technology decisions for startups
How to make sure your technology stack accelerates your path to product-market fit and beyond.
This is the spiritual prequel to my previous post about building MVPs fast on Django.
Django was the right choice for our product, a B2B data analytics SaaS. It supports rapid development, an ecosystem of pre-built libraries and SDKs (with a special focus on data), and decent-enough performance.
Your product may have a different set of requirements. While a sensible default is to use technologies you know well, it’s worth evaluating alternatives. Your choice of stack can accelerate or torpedo your journey to product-market fit.
Disclaimer: It doesn’t matter how fast you build your product if no-one wants it. Take care to speak to users and understand your market in depth, before you worry about technology stack choices.
Here are general principles that I’d recommend you keep in mind for any stack you’re using to build an MVP:
Optimise for development speed now, scale later
Write as little code as possible
Do as little ops as possible
Make it easy to hire
Make it enjoyable
Think about production on day one
Only work on value adding things
Spend a little money, not too much
Here’s the guide. As before, I’ve tried to make it succinct, specific and with links where possible. Any questions, feel free to reach out!
Guide
Walk backwards from the user experience and shortlist technology options.
Design the end user experience
Understand the requirements of functionality, performance, robustness, …
Identify the technology constraints to support that
Search for options
Evaluate your options by reading, discard obvious ones
Experiment with the rest
Continue to iterate parts of the user experience, driven by technical feasibility.1
Shortlist
Build 4-5 1 day POCs with different frameworks and see how they each feel
Make a decision on the stack
By the end, you’ll be reasonably confident that you chose the optimal stack. Keep an eye on how things evolve over the next few weeks - there’s nothing wrong with coming back again if it doesn’t work out.
Use mature technologies
Remember that there is an inherent tradeoff between the maturity of a technology, and availability of modern (time-saving) features. As a rule of thumb, you can infer this from its age:
10+ years: It will work, you’ll not encounter bugs and all possible issues are resolved on Stack Overflow.
3-10 years: It will mostly work, but you will encounter the occasional bug with no online help. APIs may feel unpolished and there may be breaking changes as the technology matures.
1-3 years: There will be bugs and obvious functionality missing. You’ll have to read the source code to fix this and (optionally) submit a PR on GitHub. There is a risk the project will be abandoned.
<1 year: This library essentially becomes an extension of your codebase.
It’s up to you to work out how much a new library will save time in new abstractions, versus the downsides (lost time, bugs) of immaturity. You’ll need to be very disciplined about this (ooh, shiny!).
Typically, you wouldn’t want to choose a technology with <3 years maturity unless it plays an essential role in the core value your product provides, that no other more mature technology can fill.
How to evaluate options
Avoid the temptation to behave like the proverbial kid in a candy store! Keep a straight head and bear these points in mind:
Avoid niche programming languages unless you know what you’re doing. The lack of SDKs and third-party libraries is a productivity drain.
Plan for now (MVP) not the future
Make sure nothing is impossible
Discount the importance of elegance for its own sake (i.e. hacks are fine)
Don’t choose things for fun or to try them out (that is what side projects are for)
Don’t use anything core (e.g. database, web framework, cloud) you haven’t tested exhaustively. Marketing pages are not to be trusted.
On that note, be aware of the implicit context in online content. There is a bias towards newer and cooler technologies deployed within large companies - aka the opposite of what you’re looking for. You might find that the best option for you is not that talked about, and that’s fine.
Don’t let theoretical/conceptual points lead software decisions. Docker containers might make sense in principle, but real world experience might suggest that the tradeoffs don’t make sense for you.
Be aware that technologies come with strings attached - ecosystem, dependent technologies, development methodologies.
Make sure you evaluate opportunities to buy (rather than build). APIs, cloud providers and no-code platforms all have the potential to save time. Where possible, aggressively outsource until you are focusing your technology work on the core value you provide.
Most of all, remember that you will not really understand a technology until you experiment with it. The perk of choosing your stack is getting to play around with new languages and libraries, and call it “work”. Embrace it (and get it out of your system)!
Thanks for taking the time to read. If you’d like to get notifications for future posts like this, subscribe below.
Typically, you’d expect available technology choices to constrain what is possible in the user experience. It’s a sign that recent technology improvements are driving the technical feasibility of your product (the “why now”), and part of this process is testing the limits of the new constraints. If you don’t see this happening, you should ask yourself why no one has built this before.