A couple of months ago I released FeedHop, a minimal web-based newsreader. Now that I've got a bit of distance from it, it feels like a good time to reflect back on what I've learned and things I'd do differently.
1. Don't start by nerding out
If your goal is to build something people want to use, I believe it's important to start with a problem you want to solve, not a technology you think might be interesting.
In my case, the problem I identified was partly to do with bloated RSS readers, but mostly to do with me wanting to try out some new technology (in this case React & Flux). While fun, this is not a good enough reason for a digital product to exist. A personal project, sure, but a product… no. It took a lot of time and feedback from some very generous people to begin to shape it into something which is of use, and I hope by iterating on it it'll become more useful still. Were I to start again, this rationale would be hammered out in a good deal more detail before one line of code was written.
That said, React & Flux are a bloody excellent combination. If you're in the business of building web apps, you should give them a try.
2. Install intercom
Intercom lets you see how people are using your site, directly message them and send automatic emails if people have been inactive for a certain amount of time. They're not giving it away (plans start at around $50 a month) but the insight you can get from it is more than worth the price tag.
3. Focus on the stats that matter
Prior to launching I'd been reading the oft-quoted book "The Lean Startup" by Eric Reis, which extols the benefits of not focusing on "Vanity Metrics" (e.g. total users, page views etc.) but on "Growth Metrics" (i.e. how well the site is growing from month to month). The thinking is that if the userbase is growing, everything else takes care of itself.
When I launched I had set up tracking for about 8 of what I considered to be "Growth Metrics" but in reality I only really look at 2 of those. The first shows many people have used the site in the last 24 hours, the second how many have used it in the last month. These are known as Daily Active Users vs Monthly Active Users (DAU vs MAU). If this ratio goes up, people are joining the site. If it goes down, people are leaving. Simple, and easy to keep an eye on.
4. Be prepared to rewrite
FeedHop parses RSS feeds from third party sites, then stores the items from that feed in a database. Initially, I was pulling in a new copy of each feed item for every person who was subscribed to it. This was a spectacularly bad idea and quickly led to a pretty massive database. After a week, I rewrote it to pull in one central copy of a feed item and only store whether people had read/saved that item or not, slashing the database size. Moral of the story - you can try and predict this stuff up front but you'll miss things. Be prepared to rewrite on the fly.
5. Be realistic about post-launch
If you're bootstrapping and there isn't a direct source of revenue for your project, the chances are you won't be able to dedicate a lot of time to it after launch. Also if it's one of a few side projects you've got going on your product will only exacerbate the problem. Be honest with yourself. If you haven't bet the farm on your project it's unlikely you'll find the same drive to keep improving as you did when pushing for launch.
6. Set up some passive advertising
The best way to learn how to improve a product is to get a constant stream of new people coming to it and test out new features to see if they improve stickiness. This is often easier said than done, particularly after any initial hubbub around the launch of your product has died down. I was fortunate in that I've got access to an audience of (hopefully) interested people via Hover States. It took me a good month to realise that I could put an ad on Hover States for FeedHop and people might click it. However, since it was up I've had a steady stream of new users every day. Being able to do this obviously depends on the outlets you have available to you, but have a think about what other means of getting the message out on an ongoing basis you might have.