On Building Better Web Apps

There are several things common among successful Web applications today. One is that they’re simple, but they get the job done. As a user, I’m more comfortable with something that doesn’t claim or try to do everything, but which succeeds and is great at what it does. Whether it’s for online publishing, social/professional networking, online collaboration, task management, a Web app that doesn’t pretend to be the Swiss Army knife of the Internet is what would usually get things done.

Give me none of that everything-including-the-kitchen-sink crap. I want stuff that works, not something that has a great spec-sheet but fails miserably at what it tries to do.

Getting Real

You think I’ve been reading too much on that Getting Real literature by 37signals, huh?

Well, I admit, yes. I do own (or at least co-own, as defined by the license) a copy and I finally got myself to read it over the course of a few hours last week. My thoughts? It’s nothing new, actually. Anyone observant enough about the workings of Web apps and services would already have an inkling as to the ideas brought forth by Getting Real. What’s great is that the people over at 37signals did great at aggregating those ideas, and actually putting them to practice. It’s like they’re one big test case scenario. And they seem to be a success story.

Also, I should know, having firsthand experience myself. In a former life, I had been part of the development team of a Web app that seemed to have much potential. Sad thing is, the app didn’t exactly fly with the intended market. And we kind of got stuck in the development process. One factor that differentiated us from the success stories: we tried to do everything–we tried to create such a big mashup of services that when the time came to launch, there was the inevitable bloat. Hence there was huge development overhead, and very long turnaround times.

Development didn’t exactly follow the whizz-bang approach espoused by the more progressive developers. Yes, we had great people. Yes, there was supposedly a great idea. But somewhere along the way, people got too obsessed with putting in everything (including the proverbial kitchen sink) and that delayed and delayed release until everyone else was leaving us behind and moving on to the next big thing. It took more than a year to come up with what could have otherwise been done in a few weeks had we followed the “release early, release often,” principle. And another year for subsequent versions? (By this time you’d think “versions” are out-of-fashion.)

Lesson learned: being a jack-of-all trades makes you a master of none.

The Conversation

A few days ago I had a very interesting conversation with one of the founders of Xackup, a startup developing specialized online backup solutions (their tagline: “because manual backups suck”). I think they’ll make the cut in today’s competitive online world. They know what their target market is looking for, being passionate users themselves, and will be developing just that (engineers scratching their own itch, so to speak). They’re cool, and they’re passionate about their work.

What apparently differentiates these guys from everyone else developing backup solutions is they’re not trying to develop for the generic market. They’re developing for a niche, or actually for several niches. This way, they won’t have to please everyone, but they’re most likely to succeed in pleasing those select few who are already passionate about the products and services they use. These are the people who are, in turn, likely to evangelize about the things they love.

For instance, the Xackup core is so simple. It’s a transfer protocol called (surprise!) Xackpack, which is supposed to rival http in high-speed transfers for purposes of backing up massive amounts of data (something like BitTorrent done backwards). The company will build its Web apps on this core, customized for their target niches–that way, pretty soon they’ll have something for everyone. For instance, their first release would be Xacktunes, which is meant to back up a user’s entire iTunes library (playlists, media, and all). What’s great: it’s supposed to work very minimal user intervention. You’ll just know it works when your hard disc crashes, you lose your iPod, or you accidentally delete your favorite tracks or all of ’em at the same time (on those occasional fits of stupidity), and you can get back your files at a click of the mouse!

Up next would be Xackmail for Outlook backup, and then subsequently a host of other specialized applications for the geeky set (Outlook? Not too geeky, though, but something I’d probably use just for backing up my SmartPhone data).

The Passion

I guess passion is one buzzword doing its rounds in today’s Web development circles. Without being passionate and inspired towards doing something, I doubt developers would be able to build great apps. Developers probably wouldn’t be putting much effort into building that app if they weren’t going to use it themselves. If the good fellows over at Xackup didn’t love using their iPods along with their iTunes, they probably wouldn’t have thought that backing up their iTunes data would be of good use. If Steve Jobs weren’t so passionate with calligraphy, we’d probably still have ugly non-GUI operating systems with monospaced fonts today!

In hindsight, I think our Web app (the Swiss Army knife-like one) could have excelled had we been more passionate about our work, and had we had the commitment to bring forth an elegantly-designed product out of our own vision. But hey, that’s one pitfall of corporate life–you don’t exactly build for yourself and for your beloved user-base. You build for the bottomline, a.k.a. the boss, a.k.a. what seems to be good from a solely marketing perspective (which is quite ironic, actually, since the bottomline’s supposedly dependent on how successful your app is market-wise).

As for me, I have brought my passion somewhere else. And this is why I’m writing here right now!