I had a fantastic time building an application in 48 hours for Rails Rumble. I built ShareLocally, a site that helps people share things with their neighbors. Instead of promoting the app (which I still think is totally awesome and plan to keep hacking at), I’m going to examine some of the things I learned from my first Rumble.

First, I wanted to thank Art/kineticac of the Browseology team and Ryan Spoon of Dog Patch Labs for holding the door open for a last-minute entry. Thanks as well to the organizers, for materializing an event that felt solid and worth hustling for. Not every event has that feeling of Something that Matters, but Rails Rumble totally pulled it off. Thanks!

Thoughts On Short-App Challenges

This is as much a product management challenge as it is an engineering challenge, if not moreso. Building things (and building things quickly) is only important if they provide value to the user. Although I’m used to working with a limited timeline at my bootstrapped startup, 48 hours is way more intense, and the feature prioritization is even more critical.

Scoping is essential for this sort of project, and ShareLocally was likely too large. It seems that the most successful apps were the ones that could have been a single feature of another application, polished to a great degree.

I’ll admit that I’m kinda tired of the API apps (Twitter, primarily) that are so popular, both in the Rumble and on TC, but I understand why they’re built. API apps allow you to build on an established userbase or dataset and make it easy for users to sign up. They also make the notion of “a single function app” far more appealing, since they can fit into an ecosystem of apps.

Another thing I would do differently next time is to build an app that requires absolutely no sign-up process. We’re all so used to signup processes because they’re good for long-term stickiness and allow users to keep their information private. For a one-shot weekend app, decreasing the barrier to use is essential to get people using it and would have saved a few hours of coding time.

Local is bad for a quick app unless you have pre-seeded the data. If there’s nobody within 50 miles of you on ShareLocally, it’s a wasteland. Local apps require a larger degree of penetration in order to provide utility, but conveniently also can exist in islands. Again, possibly okay for long-term viability, but not really instant usefulness.

Another, and an obvious one: I’d work with a designer next year. Although I had fun working up the layout for ShareLocally and still like the hand-drawn feel, that time could have been spent coding. Now I just need to find a designer whose work I feel good about.

Unnecessary Features

I’m not sure if I’d build a feature like the email proxy system again, but I had a lot of fun doing it. Basically, all emails go into a wildcard account and get processed by the app every minute according to access controls.

Similarly, batch request notification seemed like a nice feature, but probably was too subtle to spend as much time on it as I did.

As far as system set-up, that went pretty smoothly. I love monit, for the record, and can’t imagine feeling comfortable setting up a server without monit. I’ve even got monit accessible (although behind basicauth) at http://monit.sharelocally.org/.

I also did a few unnecessary things because I wasn’t sure what the load would be like, such as setting up asset hosts (assets3.sharelocally.org, etc). Fun from a technical perspective, but load hasn’t been enough to really justify in retrospect (as indicated by the ShareLocally NewRelic account)

Sleep!

I’m not sure if this would generalize, but I’m really happy I slept on Friday night. Yep, that’s right: I got a full night of sleep during the app. Initially, this felt really indulgent when I woke up and looked in the IRC channel about everyone still going strong from the previous night, but at around 8pm on Saturday I was doing awesome and sipping on my favorite Tieguanyin, which let me stay up all night on Saturday. When everyone else’s commits were flagging, I was still going strong. Although I haven’t pulled an all-nighter since college, it was surprisingly easy. Things to remember: food and water are essential, along with plenty of caffeine. If people actually stayed up all 48 hours, my hat’s totally off to them. If not, sleep the first night so you can jam out until the fat lady sings on sunday.

Use Awesome Plugins

GeoKit was really amazing plugin to work with, and I heartily recommend it to anyone building out a location-based service. I
also had a lot of fun building the map and directions on the user home page with the Google Maps API. Although I hadn’t worked with either of these technologies before (or really done anything location-based), they were really super-easy to get started with and had almost no technical overhead.

I’m particularly happy with the regular-expression-based location-centric search I built into the app, and it meshed really well with an open-source regex-highlighting jQuery plugin I had written for Stormweight. When you find something in search, the expression that matches your query is actually highlighted on the client-side, even if it’s a complicated regular expression. Using your own plugins is awesome, because you know exactly how everything works. This is also a good example of how sweet it is when you extract common functionality.

An amazing weekend

I had a really great time doing this and learned a whole lot in the process that I expect will generalize to building startups. I’d love to do this more regularly, but I imagine that few other people are quite that nuts. Building new stuff is fun, and even more so when other people are on the same timeline.