I like making things. If I have a problem that I want to fix or just have an interesting idea, I’ll try to build an application. So far, I’ve created the following:
WikiLink (Source) - a Python script that provides a fun way to explore Wikipedia by selecting several random links from the current article
TigerTalk - a Node.js chat application for Princeton students to talk to each other
Out of all of the above, I spent the most time building TigerTalk. Despite not having a lot of users, I poured hours into making new features and putting in additional functionality like the ability for users to create new rooms and having a dinging noise play whenever a message is received. Why? I thought that the next little feature would somehow convince people to start using the application and that TigerTalk would finally catch on. Boy, was that a dumb idea.
Web Timer, on the other hand, has fared a lot better with a user base of a couple thousand. I use it myself, and it solves a very real problem that I have of losing track of how I spend time online. Now I can see that I use 11.4% of my time on the Web to go on Facebook for an average of 40 minutes and 23 seconds every day. Neat.
I am now a firm believer in building an MVP and showing it to users before devoting hours into a project that might completely go to waste. Sure, you’ll get some experience out of building a system with a ton of features, but you could have spent that time building something that people will actually use. It turns out that keeping your applications simple has a two-fold benefit: it lays naked the core idea behind your application so you can easily tell whether it resonates with users or not, and it helps you avoid sinking too much time into a project that will never take off. It’s important to know how to work hard and battle through hard times, but it’s just as important to know when to quit if something just isn’t working. As long as you keep it simple, your chances of success will be much higher.