Tech Prototyping - 5 tips for developers
Tags: webdev, productivity, prototyping, tips
Published: 2020-08-13 10:12:29

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
![A list of crossed out bullet points, only the last one has a checkmark.](https://dev-to-uploads.s3.amazonaws.com/i/v36s5ogdjb4seo5vihsh.png)
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
![A diagram of many small iterations](https://dev-to-uploads.s3.amazonaws.com/i/t7od0ofcx9tmsipo9xab.png)
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
![Thought bubble containing different tools, one has a checkmark](https://dev-to-uploads.s3.amazonaws.com/i/oqsoshwlpymojgqfmnhv.png)
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](https://www.liip.ch/en/blog/nexplorer-or-a-steep-learning-curve).

# 4 Love the problem, not your solution
![A heart between icons of solution and problem, an arrow pointing from the heart to the problem](https://dev-to-uploads.s3.amazonaws.com/i/0zocf8rcoesbbdmy5ze0.png)
It might be taken out of context here, but the quote ["Love the problem, not your solution" by Ash Maurya](https://blog.leanstack.com/love-the-problem-not-your-solution-65cfbfb1916b), 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
![A house and a bridge, the house has a checkmark next to it, the bridge has a cross](https://dev-to-uploads.s3.amazonaws.com/i/35ybp4hefggrk4ljj7f3.png)
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
![Thought bubble containing a path with three little flags on it](https://dev-to-uploads.s3.amazonaws.com/i/um54yyzw617amp77zs3s.png)
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](http://buymeacoffee.com/pthormeier)!

[![Buy me a coffee button](https://dev-to-uploads.s3.amazonaws.com/i/x55hp6jopwyy161d8e2u.png)](http://buymeacoffee.com/pthormeier)