TL;DR:
If you want to build an MVP fast, avoid the fresh-of-the-press technology, think in the now and not in the tomorrow, rely on best practices, focus, focus, focus and do a premortem before you start.
While working on a larger project, I had another idea for a web app I wanted to build without spending too much time. Before I started working on it, I applied the new idea to the project itself. Are you confused already?
Let's premortem!
The idea for the new project was a simple tool to perform so-called premortems with your teams. What is a premortem?
A premortem is a managerial strategy in which a project team imagines that a project or organisation has failed and then works backward to determine what potentially could lead to the failure of the project or organisation.
Wikipedia
The goal of the web app is to enable asynchronous premortems.
Before I started the project, I performed such a premortem with myself (That sounds sadder than it is). So, why would I've ended up without a working MVP after three weeks?
- I was distracted by new shiny tools and frameworks.
- I spent too much time on vanity tasks.
- I added too many features that were not necessary for an MVP.
- I tried to make everything reusable.
- I wanted to do everything the right way
After this introspection session, I found myself looking for remedies to prevent these things from happening.
I was distracted by new shiny tools and frameworks.
Of course, everyone knows a new shiny tool is born every day. And watching a short video about a new framework can give you the feeling of being stupid not to use it for your next project. It's so much better than everything that came before. How can you still work with the tool you tried yesterday if tomorrow there will be a tool that allows you to do it in half the time?
Of course, highlighting only the improvements omits all the downsides new tools bring to the job. As a product guy who tries to code, the biggest downside has been the need for more tutorials and examples when jumping into the latest and greatest tech.
And since I had this experience already a couple of years ago when I jumped into the world of Svelte (I watched "Rethinking Reactivity" by Rich Harris and was hooked), I tried to avoid it this time around.
I hadn't coded anything for over a decade at this point, and since I moved from my operational role at my company to a strategic one, I wanted to have a deeper look at it.
Fast forward two years, and I feel lucky to have found Svelte for my project ideas. In the best sense, it took me back to the early days of the web in the nineties.
<script>
<style>
<html>
The structure felt very easy for me to get back into the world of JavaScript, HTML and CSS. And the great tutorial, docs and friendly community did their part for a smooth comeback. That being said, finding tutorials and examples for implementing other tools and services sometimes felt like the search for a needle in the haystack without knowing if there was a needle to begin with. Thankfully, Svelte has grown tremendously, and you'll find everything you need to build your MVP easily.
So, no htmx, solidjs or fresh for me.
I spent too much time on vanity tasks.
I started my career as a UI/UX designer and always liked working on new interface concepts and ideas. And one can spend endless hours on hover effects, colour schemes and dark modes, but it can become a distraction and a project onto itself.
Because of all the available tools, I often agonised over whether I should add a wonderfully styled and animated combo box with a search function. Squaring the web for the best library to integrate or thinking of building my own component would allow me to finally customise it the way I truly wanted it. This would also bring my MVP to the front page of Hacker News by people in awe of the smoothness of the opening animation of the menu while typing into the input field next to a custom-designed cursor with a slightly lighter grey than the standard one. I only realised, after many hours, that a basic dropdown should be fine.
Using standard elements or sometimes component libraries can speed up the MVP process drastically. This also unlocks a precious feature: It's much easier to drop an idea built with standard elements than to admit that the user experience would be far better by replacing your fancy dropdown with a simple radio button group. The less attachment you have to ideas in this phase, the better.
In this case, Tailwind CSS/UI did the trick for this project, giving me a lot of flexibility and speed without spending too much time with the intricacies of CSS. So, whatever you think of Tailwind CSS regarding code readability in a component-driven MVP environment, it's a no-brainer for me.
I added too many features that were not necessary for an MVP.
Finding the right moment to release the first version of the MVP is still challenging. Does it add any value without the additional features that I had in mind? Is it just a glorified StackOverflow clone (probably) without any special sauce? Will I look back and think if only Google OAuth would have worked on day one? (I’m waiting on Google to verify my credentials.)
Honestly, there isn't a good and correct answer to this. You'll never know with certainty why a project is a success or failure. Of course, you'll find tons of stories from people that have built successful products that will tell you exactly why it was a success. But mostly, it's only apparent in hindsight, or it's wishful thinking by the creator to know why their project worked when others didn't. But as Wayne Gretzky once said: "You miss 100% of the shots you don't take." (I couldn't have written it better; that's why I googled it just now and pasted it into my blog post.)
I tried to make everything reusable.
When coding a new component, this thought crosses my mind sooner or later: Wouldn't it be great to reuse this in other projects? This usually ends in hyper-dynamic components covering all potential future applications, real or fictitious. Though it sounds good at first, it's poison for an MVP. Don't get me wrong, reusability is great, but it has its time and place. However, over-engineering a component opens the door to unpredictable behaviours and can make debugging a nightmare. At least for me.
When it comes to components, one can get carried away and lost in a nested structure that would challenge the most intricate of stacking dolls. Finding a good balance is the key.
My middle ground is avoiding repetition within the current project. At the same time not thinking about future (non-existing) ones. The way I approach this in practice is by measuring my inner frustration level in three steps:
I wanted to do everything the right way
This is the hardest part. Even though I spent the last decades in Webdev as a founder/CEO of Divio, I was forced to become a jack of all trades, master of none. I learned about a vast range of web development, deployment, security and reliability topics but never deep enough to apply it in practice. That's where our fantastic team of specialists came in. Having no longer access to this brain trust puts me in a strange situation: I know what I should do but not always how. (Sometimes ignorance is bliss). So, how deep down the rabbit hole does one go when it comes to authentication, security, DOM, DB or CI/CD?
My answer: Take the path of least resistance.
In my case, that meant:
- Tailwind CSS/UI for the frontend
- Sveltekit without SSR (for the moment, at least)
- Pocketbase as my BaaS (one shiny new thing, couldn't resist)
By choosing these technologies, I could rely on the existing know-how the community had already built up. I found tutorials and examples everywhere, which saved me from reinventing the wheel, and I focused on the bits and pieces that made up the product, which allowed me to avoid project failure and reach MVP status within three weeks.
If I had stuck to my own rules and not taken Pocketbase for a spin, the project would've been done in an even shorter amount of time. That being said, Pocketbase is a great choice for such MVPs. It's a nimble piece of software by Gani, and tutorials and examples are increasing daily (it just took me a moment to find them).
Is Let's premortem the biggest thing since sliced bread? Hell no. Is it a simple web app that anyone with access to a computer and an internet connection could have built? That's a proud yes!
Top comments (0)