DEV Community

Cover image for How overcomplicating our MVP killed Snaptier
Miguel Piedrafita
Miguel Piedrafita

Posted on • Originally published at miguelpiedrafita.com on

How overcomplicating our MVP killed Snaptier

If you followed me on Twitter last summer, you've probably heard about Snaptier. After finally launching UnMarkDocs on my own, I wanted to try something new. All my projects had been solo until then, so I contacted Dominic (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) but we decided to pivot after I got notice of the development of the aforementioned project.

How overcomplicating our MVP killed Snaptier

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 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

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

How overcomplicating our MVP killed Snaptier

How overcomplicating our MVP killed Snaptier

How overcomplicating our MVP killed Snaptier

How overcomplicating our MVP killed Snaptier

How overcomplicating our MVP killed Snaptier

How overcomplicating our MVP killed Snaptier

Never-seen-before screenshots of the Snaptier UI, designed by Niklas

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

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

We internally decided to announce Snaptier was dead, but still no one said anything publicly

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 (probably also the last one).

How overcomplicating our MVP killed Snaptier
Internal message I sent when I pushed the code that made everything work

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
Snaptier post-mortem

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, and got an initial, shippable version in around a week.

How overcomplicating our MVP killed Snaptier

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 Henrik's fantastic post on the topic.

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 and Niklas on Twitter and check out their new, awesome product Songmash. You can also read more about how I built my next product in less than a week and give Blogcast a try.

Top comments (0)