Building lean tech prototypes
Hitting the ground running while building your product
Starting new projects is hard. Not knowing if they will be successful is even hard. In the startup scene nowadays, tech people are expected to build bigger and more complicated products faster and with less people. Feedback loops need to be extremely short, deployments are multiple per day and release cycles weekly, if not shorter.
In this environment, it is essential to approach product development in a smart and effective (not necessarily efficient) way. Unfortunately, most of the literature we read as developers, is definitely skewed towards stability, predictability and large upfront investments into tooling and laying a solid foundation. A mindset with larger companies in mind. With agile and lean methodologies gaining popularity, the expectation of always knowing everything in advance is at least gone. And there is, to a degree, acceptance that a lot is still unknown and that’s ok.
Unfortunately, a lot of this mindset that we learn in university or in our first jobs, does not translate well is we try to build something of our own from scratch in a startup.
A lot of this stems from the fact that it’s not easy to go on stage and preach about doing things quick and dirty, cuttung corners or building unsustanable products. Even though, in many cases, this is what allows a company to survive until it can afford to do things the right way.
What you should focus on when starting with your tech startup
Startups are very different from regular companies. Often times our formal education and our careers don’t prepare us adequately for this endeavour. With so many things to learn and try while starting a business, it’s always beneficial to build on top of the advice of others. This is exactly the aim of this article - I’d like to share some lessons that …
To me, excelling in the very first steps in building a new product, especially in a startup setting means knowing the boundaries between moving fast while also not backing yourself up to a corner and creating something that will later on be too difficult to “fix”.
This is exactly what I want to present here. What are the things that should be put into consideration so that the project moves as fast as possible, without speeding into a dead end, or creating something unethical (e.g something that’s plain insecure)?
it’s a balancing act between speed and quality that is often opinionated. There are a few guiding principles that I have which help me make decisions in this balancing act:
Be lean — As a fan of the lean startup framework, a guiding principle for me is to gather feedback as soon as possible and to not build things I don’t absolutely need in order to prove a hypothesis. This means, even if I do need to build some software, I’ll try to deliver something within a few weeks maximum. This usually ties my hands and closes the door to more intricate solutions
Build scalable architectures — This can be a tough one. I’m willing to cut corners on many aspects of an initial experiment, but I’d avoid making systems that plainly cannot scale, at least not easily. For instance, I’ll always try to keep services stateless and horizontally scalable. This is usually not that difficult, it’s the right thing to do and saves a lot of headaches if the project lives beyond a few months.
Create extendable data models — You can change the code of your prototype and make it nicer. Changing you data model, however, can be trickier. There are some things you can easily change in a database schema, for instance, but others, not. For this reason, when I think about “permanent” things like APIs and schemas, I spend the extra time to ensure as the project grows I can extend the model without having to redo everything. Redoing is also definitely possible, but it’s a bigger task. For me, spending a bit more time upfront is worth it.
Use third party tools, but be mindful — Everyone uses tools and services. Especially in the beginning, it’s highly beneficial to not re-invent the wheel and use other provider. That’s all good, but I personally use the same discretion here as I do with the previous point of data models. How easy is it to replace that tool? It’s there a major lock-in there? Many services are aware of this line of thinking and they offer very generous starting tiers, just to become very expensive later on. Or they don’t provide all the functionality or data that you will need in the future. In any case, it’s often difficult to decide. For instance, should you use a cloud provider like AWS, GCP or Azure? There’s undoubtably vendor lock-in, it’s surely more expensive in the long run than buying/renting servers. It’s a huge project to switch in the future. And yet, not having to fiddle with hardware, servers, operating systems etc. is often a decisive factor in the speed and ultimately the success of a project. It’s a tough call. For me, I can say that as someone without a huge devops background, the simplicity of the top cloud providers was critical. If I was verse in setting up and running servers, it might have been different.
Are there any other things that you consider and are important to you when you make tech decisions early on. Let me know in the comments.
Building lean products and prototypes has a lot of moving parts and involves making countless smaller decisions. I will try to help with these decisions in their respective linked articles. Consider subscribing to my Substack for more.