I have to say I disagree with this. Sure your app may break, but the rarity of being featured completely outweighs the bugs fixes. The pure exposure of a feature will help with other press coverage which will help with long term customer acquisition.
As tempting as it may be, never do "side" projects while in the confines of your full time gig. There are lots of sticky legal areas. Your company could possibly even claim rights to your "side" project since you worked on it using company resources (computers, office, etc).
Developer here. I wanted to try out Parse for mobile apps, so I came up with something fun to build: a messaging app that automatically translates your message into Pig Latin and other gibberish languages.
For the backend, I used Parse and was really pleased. From a developer perspective, Parse was really easy to use and integrate. I had previous experience with Mongo, so their data structure wasn't unfamiliar. Both their iOS and Android SDK's were nice to use. I've used lots of different SDK's in mobile apps and I would say Parse ranks up there in terms of ease of use and documentation. And from someone who develops both iOS and Android, I really appreciated that there was a consistent naming convention for their methods across both platforms. I really hate when an SDK has slightly different names for each platform.
My only ding for Parse would be support. They recently transitioned their support forums from an in-house forum to using Stackoverflow. All the old threads are still indexed by Google and show up in results, but these old posts reference older versions of the Parse api. And I found it a little hard to sometimes find what I was looking for in SO. I will say that the Parse documentation is really nice. So I only had to turn to the support forums for some rare cases.
When I read news on my phone, I bounce around multiple news apps, scanning all the headlines but never really reading any of the articles. But I still knew a lot about what was going on because the headlines had a lot of information. This gave me the idea for News Cues. News Cues collects current news stories from multiple sources, uses some NLP and AI logic to filter and sort the stories, and then presents it in an easy to digest format.
I use Netbeans for java and used it when I started working with Ruby. But I switched to RubyMine and really enjoy it. It took me a while to convince myself to pay for an IDE after previously using Netbeans and Eclipse, but the cost isn't high and it has really made me speed up my ruby work.
I think it is a new approach to solving a broader problem, which is how do you gather the knowledge of a group of people efficiently. Sure, Tpstry is built using cool technologies (Rails, Mongodb), but using an interview process to gather structured data is what I find most interesting.
We've built Tpstry to modify the interview questions based on previous answers. So new lines of questions are opened and others are closed. This helps with the user experience because it only presents the user with relevant questions.
The main focus of the site is to help families gather and collect memories that you can't find anywhere else besides in the minds of their relatives. Questions like the ones in the blog post can't be found in newspapers or historical records. So you need an easy way to gather this information. That is why we focus on answering questions.
Lots of people use blogs and wikis to collect family history. For those sites, the user has to spend time thinking about what to write and then compose the text. On Tpstry, we ease the process by presenting quick questions to answer. For the user, this is much simpler. They either know the answer or they don't. And if they do know the answer, they only have enter a short amount of text. So this speeds up the data entry process.
Plus, once a question is answered, the information is stored in a structure manner so that it can easily be reused in other ways. An example of this is that Tpstry takes all the answered questions and automatically creates a website for you.