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 (the same idea as what Packagist just launched) but we decided to pivot after I got notice of the development of the aforementioned project.
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 with an architecture that'd allow for much more extensibility).
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.
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).
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. At this point, I had to force myself to work on it (instead of passion-powered development). 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.
We finally decided to kill the project in March, but we kind of resisted saying 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.
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 to 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).
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.
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.
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.