How overcomplicating our MVP killed Snaptier
Tags: story, telldev, startup
Published: 2020-01-23 08:15:11

---
title: How overcomplicating our MVP killed Snaptier
published: true
tags: story, telldev, startup
canonical_url: https://miguelpiedrafita.com/snaptier-mvp/
cover_image: https://miguelpiedrafita.com/content/images/2019/11/image--1--1.jpg
---
If you followed me on Twitter last summer, you've probably heard about [Snaptier](https://snaptier.co). After finally launching [UnMarkDocs](https://unmarkdocs.co) on my own, I wanted to try something new. All my projects had been solo until then, so I contacted [Dominic](https://twitter.com/dmfj) (friend and fellow teen coder) and we started brainstorming ideas for a new project.

We initially wanted to build a marketplace for Composer packages (same idea to [what Packagist just launched](https://packagist.com/vendors)) but we decided to pivot after I got notice of the development of the aforementioned project.

![How overcomplicating our MVP killed Snaptier](https://miguelpiedrafita.com/content/images/2019/06/Image-2019-06-02-at-2.31.12-PM.png)

After brainstorming other ideas, we decided to go for a service that'd automate common programming tasks. The idea was to make certain tasks as simple as connecting your GitHub account and merging a PR (kinda what [Laravel Shift](https://laravelshift.com) does, but for other types of things).

While building the app, it became evident that our design skills weren't as good as we'd have liked, and we decided to bring in Niklas, who I'd met earlier and is an awesome designer.

![How overcomplicating our MVP killed Snaptier](https://miguelpiedrafita.com/content/images/2019/06/Image-2019-06-02-at-2.39.46-PM.png)

While Niklas worked on the UI and frontend and Dominic managed servers, I started creating a backend framework that abstracted all the GitHub logic into a pleasant to use fluent interface. This turned out to be a horrible idea because it slowed down the whole development of the product (I'll talk more about that later).

We continued building Snaptier through the summer, and we had a great time. I usually live-coded on Twitch, we had weekly meetings, we developed inside jokes with the community in our Discord insiders channel and even recorded some podcast episodes (although we never got to release them).

 ![How overcomplicating our MVP killed Snaptier](https://miguelpiedrafita.com/content/images/2019/06/snaptier.wip_.png)

 ![How overcomplicating our MVP killed Snaptier](https://miguelpiedrafita.com/content/images/2019/06/building.snaptier.wip_.png)

 ![How overcomplicating our MVP killed Snaptier](https://miguelpiedrafita.com/content/images/2019/06/snaptier.wip_coming-soon.png)

 ![How overcomplicating our MVP killed Snaptier](https://miguelpiedrafita.com/content/images/2019/06/snaptier.wip_dashboard.png)

 ![How overcomplicating our MVP killed Snaptier](https://miguelpiedrafita.com/content/images/2019/06/snaptier.wip_login.png)

 ![How overcomplicating our MVP killed Snaptier](https://miguelpiedrafita.com/content/images/2019/06/snaptier.wip_settings_account.png)

 ![How overcomplicating our MVP killed Snaptier](https://miguelpiedrafita.com/content/images/2019/06/snaptier.wip_settings_account--1-.png)

<figcaption>Never-seen-before screenshots of the Snaptier UI, designed by <a href="https://twitter.com/shroudedcode">Niklas</a></figcaption>

Remember that fluent interface I talked about earlier? I spent most of the summer working on it, making it async and improving it, but still didn't manage to get everything working. It got to a point where exceptions weren't thrown and it was almost impossible to debug anything. I got to a point where I had to force myself to work on it until I burned myself out completely and started working on other things.

Niklas and Dominic ended up doing the same and development paused without anyone except us knowing. Everyone moved on to work on new projects, but we totally forgot (or procrastinated on) telling this to the people who had been following the product since the start.

![How overcomplicating our MVP killed Snaptier](https://miguelpiedrafita.com/content/images/2019/06/Image-2019-06-02-at-3.37.54-PM.png)

We finally decided to kill the project in March, but we kind of resisted to say it publicly for some reason. I guess it's the emotional component of pronouncing dead something you've poured so many hours of your life into.

![How overcomplicating our MVP killed Snaptier](https://miguelpiedrafita.com/content/images/2019/06/Image-2019-06-02-at-3.51.29-PM.png)
<figcaption>We internally decided to announce Snaptier was dead, but still no one said anything publicly</figcaption>

Then, in May of this year, I started working on the backend again. There was no reason for me to do this other than to prove myself I could finish the abstraction I had taken so much time to build. I finally managed to get it working and produce [our first PR](https://github.com/m1guelpf/testing-license/pull/4) (probably also the last one).

![How overcomplicating our MVP killed Snaptier](https://miguelpiedrafita.com/content/images/2019/07/Image-2019-06-02-at-3.57.34-PM.png)<figcaption>Internal message I sent when I pushed the code that made everything work</figcaption>

Still, we were reluctant to restart the project. We'd also let our original domain (snaptier.co) expire and someone had grabbed it and redirected it to some gossip website. With all this in mind, Niklas wrote and posted a post-mortem in the public channel.

![How overcomplicating our MVP killed Snaptier](https://miguelpiedrafita.com/content/images/2019/06/Image-2019-06-02-at-4.01.56-PM.png)<figcaption>Snaptier post-mortem</figcaption>

Niklas already summarises all the lessons we learned, but the most important one, in my opinion, is that **MVPs should be short and small versions you can later iterate on**. I applied this mindset to my next product, [Blogcast](https://blogcast.host), and got an initial, shippable version [in around a week](https://miguelpiedrafita.com/building-blogcast).

![How overcomplicating our MVP killed Snaptier](https://miguelpiedrafita.com/content/images/2019/06/Image-2019-06-02-at-4.06.28-PM.png)
<figcaption>How building products should work. Stage 1 is the MVP and the next stages represent iterations. The benefit of building like this is that people can use your product since the MVP and don't have to wait until the full-fledged version is ready. Illustration from <a href="https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp">Henrik's fantastic post on the topic</a>.</figcaption>

Even though it didn't exactly end well, I consider Snaptier a success. I had fun and learned a lot, both about code and about how to build products. I hope that I can go back and finish Snaptier someday but for now, it stands as an important lesson.

_You can follow_ [_Dominic_](https://twitter.com/dmfj) _and_ [_Niklas_](https://twitter.com/shroudedcode) _on Twitter and check out their new, awesome product_ [_Songmash_](https://songmash.app)_. You can also read more about [how I built my next product in less than a week](https://miguelpiedrafita.com/building-blogcast) and [give Blogcast a try](https://blogcast.host)._