Imagine the following: You're approached by a client with an amazing idea - but without enough money to realize it. They need to convince some angel investors and test the market, ideally with a somewhat working product: A tech prototype.
Tech prototyping is an entirely different ballpark from building long-term large-scale products. For developers coming from the latter it may be hard to adjust their mindset: Ideally, the produced code is future-proof, follows established patterns, is well-documented, you name it. It was difficult for myself, too, which is why I want to share my five key learnings.
1 Cut down on features
Focus on what's necessary to get the job done. Many people know the MVP, the Minimum Viable Product, which is a good starting point. Especially for new products, there's also the MMP - the Minimum Marketable Product. Those two aren't necessarily the same. Focus on the MMP and leave out everything else.
Try to reduce the number of necessary features by restructuring the product - find ways how your product works without a login or even without a database. The time you've won is essential to keep costs low.
2 Be quick and agile
Agile development has been around for quite some time now. The agile manifesto recommends to deliver working software in small iterations and respond to changes rather than sticking to a plan. Those principles work on all sizes of projects. Develop an agile mindset and stick to it.
Try to deliver parts of the product as early as possible and work closely with your stakeholders. Do check-ins and feedback rounds every day. This way, you can respond to changes earlier and adapt the product quicker. Continuous deployment is essential for small iterations.
3 Pick the right tools
Although you know best which tools you can work with and which tools make you most efficient, why not try something new every now and then? Every prototype is a learning opportunity. A prototype is made to test a hypothesis, not to last for years. Take the opportunity to try a new framework, maybe try a document oriented database instead of relational one.
I've written a blog post about how to choose your next tech stack on the Liip website.
4 Love the problem, not your solution
It might be taken out of context here, but the quote "Love the problem, not your solution" by Ash Maurya, the inventor of the lean canvas, holds true nevertheless. The so called "innovator's bias" hits entrepreneurs and scientists alike, but it can also hit us developers.
It's important to keep in mind that your prototype exists to test a hypothesis. It might be the single most amazing piece of code you've ever written, but in the end its purpose is fulfilled rather quickly. Don't love your code, love the problem you're examining.
5 Don't over-engineer
But don't under-engineer either. At least not too much. When we as developers see a problem, our first reflex might be to think about patterns we could use to solve it. We try to anticipate how a feature will grow over time and try to come up with solutions upfront to reduce complexity down the road.
Most of this is not necessary when creating a tech prototype. A "quick and dirty" approach is often enough, as long as it works. You don't need a strategy pattern if you're only ever building one strategy. You don't need complex database abstraction if you're only using three tables in SQLite. You don't need comprehensive end-to-end testing when unit testing some core components is enough. The definition of over-engineering is drastically smaller when you're prototyping.
Takeaway thoughts
What you learn in courses and schools helps building large and long-lasting things. But when it comes to prototyping, these ingrained principles might even be a hindrance to achieve your goal fast. Good is often good enough and perfect is the enemy of done.
Switching a mindset is always hard
What's your experience with building tech prototypes? Which of those tips do you find most helpful and why?
I write tech articles in my free time. If you enjoyed reading this post, consider buying me a coffee!
Top comments (0)