On my list of horrendously bungled acquisitions, I put Delicious near the top. Since its acquisition by Yahoo in 2005, the biggest user-facing change to the site was a visual refresh in 2008. Even with this rampant feature stagnation, I’d stuck with the site because it solved a daily need for me — bookmarks anywhere.

Yahoo’s strategic negligence is mind-boggling. In a world of exponentially increasing information, coupled with increasingly different ways of accessing it, the idea of investing in a social service that tells you precisely what your users care about strikes me as a no-brainer.

Fortunately, nature abhors a vacuum and Marco Arment’s Instapaper has deftly stepped in to replace Delicious. I spoke with Marco via email to understand the origins of Instapaper, the valuable lessons he took from his first company — Tumblr — and how he manages one of web’s most useful sites as a one-man shop.

RANDS: Where did the idea for Instapaper originate and how long until you had a usable product?

MARCO: In the fall of 2007, I had just switched to the iPhone, and I had a long train commute every day. I never knew what to read on the train, but I’d find stuff all day at work that I didn’t have time to read, so I made Instapaper as a simple, one-click link-saving service for myself to time-shift links from the work day to my train commute.

The original web app took only a single night to write. It was usable, but it was very simple.

Over the next couple of months, I added a few useful features, most notably the “text” mode to strip articles down to iPhone-formatted text. This was so the EDGE-only original iPhone could download them quickly and keep more tabs in RAM without needing to reload them when I was potentially underground and offline.

When did you know you had something viable on your hands?

I just used it myself and didn’t tell anyone for a few months. I then showed it to a couple of friends. After a week of using it, they were already raving that it was amazing and it changed the way they read, so I gave it a few nights of polish and posted a simple link to it on my blog.

Within days, it had thousands of users and was getting widespread acclaim. I had no idea it would get so big so quickly.

What’s your favorite stat or fact regarding Instapaper?

Most people assume that online readers primarily view a small number of big-name sites. Nearly everyone who guesses at Instapaper’s top-saved-domain list and its proportions is wrong.

The most-saved site is usually The New York Times, The Guardian, or another major traditional newspaper. But it’s only about 2% of all saved articles. The top 10 saved domains are only about 11% of saved articles.

You’re a one-man shop and are, among other things, developer, support, and operations — how do you pull that off?

A lot of coffee and Phish.

Were there design decisions you made early on in order to manage that? What were they?

Absolutely.

The biggest design decision I’ve made is more of a continuous philosophy: do as few extremely time-consuming features as possible. As a result, Instapaper is a collection of a bunch of very easy things and only a handful of semi-hard things.

This philosophy sounds simple, but it isn’t: geeks like us are always tempted to implement very complex, never-ending features because they’re academically or algorithmically interesting, or because they can add massive value if done well, such as speech or handwriting recognition, recommendation engines, or natural-language processing.

These features — often very easy for people but very hard for computers — often produce mediocre-at-best results, are never truly finished, and usually require massive time investments to achieve incremental progress with diminishing returns.

If a one-person company is going to build a product, it can’t have any of those huge time-sink features. At most, I can afford to have one or two components of moderate complexity, such as the HTML-to-body-text parser and the Kindle-format writer. But even those are barely worth the time that I put into them.

What were the biggest lessons you took from Tumblr that made the design, development, or deployment of Instapaper easier?

Tumblr didn’t have a dedicated server administrator until a few years into its life, so I had to be our de facto server administrator in addition to my primary developer role from Tumblr’s start until we had 48 servers handling about 5,000 requests per second.

Since that’s a sizable infrastructure, but we had very little time to devote to maintaining it, I had to choose mature, stable technologies with great tools and very low administration needs. And I built Instapaper on the same technology: PHP 5 with a custom high-performance MVC framework, MySQL, Memcache, Apache, and CentOS, on high-end dedicated hardware.

This proved invaluable to both Tumblr and Instapaper, since I don’t need to deal with webserver processes crashing, corrupted databases, or any serious platform issues. All of these tools are used by many other companies with deployments much larger than these, so nearly all of the bugs get worked out long before they get a chance to affect us.

The result of all of this platform conservatism is that I can spend my time improving the product in meaningful ways instead of fighting with my server software.

What part of Instapaper’s infrastructure are you most proud of?

The bookmarklet has a mechanism to save pages from sites that require logins for full content, such as the Wall Street Journal and Harper’s, by sending a copy of the page’s HTML from the customer’s browser to the server. It’s like automating the “Save as…” menu item: if you have your own account for these sites and can see the page in your browser, you can save it to Instapaper.

The way it does this is ridiculous: instead of calling a simple GET request to save the page, since an entire page’s contents would quickly overrun any URL-length limits in the stack, it injects a FORM with a POST action and populates a hidden value with the page contents.

But form-data requests from browsers aren’t Gzip-compressed, so the resulting data is huge and needs to be sent over people’s (often slow, often mobile) upstream connections. So I found an open-source DEFLATE implementation in Javascript — really — and the bookmarklet compresses the page data right there in the browser before sending it.

The whole procedure is hideously complex, but works incredibly well.

Instapaper integration seems ubiquitous in any information consumption application that’s been released in the last year – how did that start?

This started as a fortunate side effect of having a few influential developers who were fans of Instapaper, most notably Loren Brichter (Tweetie, now Twitter), Craig Hockenberry (Twitterrific), and Brent Simmons (NetNewsWire), who integrated send-to-Instapaper features into their respective products a long time ago. And since the Twitter and RSS client markets are so competitive and innovate so rapidly, many other developers quickly followed suit.

Now, it’s almost always a highly requested feature for new content-finding and content-consumption apps, especially on iOS. I’m just honored and humbled that it has become this widespread.

My impression is your feature development process is very iterative — do you start with something that you want yourself and then slowly develop for your users? Does it work? How do you know when you’re done?

That’s correct. I don’t plan specific, major releases very often — I just incrementally build on the product in development, test features on myself for a while, cancel those that don’t work, and roll up the successful ones into a release every few months.

Generally, I know I’m done because as I’m testing the migration from the current in-store version to the new version, I cringe at how bad the in-store version is relative to my shiny new development copy. I think, “I can’t believe *that* is what customers are using right now, when they could be using *this*.”

That’s when I freeze new features, fix any known bugs, polish any rough edges, begin final testing, and prepare to issue the release.

What productivity tip have you discovered that now you can’t live without?

Keep a to-do list.

A real one. One that you actually use and update throughout the day. It doesn’t need to be fancy, like the getting-things-done task managers — I use TaskPaper, which is essentially a text editor with optimized syntax highlighting for to-do lists, against a text file on Dropbox.

I’ve never been a note-taker. In high school, I was that smartass kid who never had any notebooks or anything on his desk in class. Just a blank desk to slowly fall asleep on. I thought I could just keep track of everything in my head, which is true in high school if you’re a smartass slacker, but doesn’t work very well after that.

If a task isn’t written down in a list or set to alert me in iCal, it’s gone. Forgotten. Doesn’t get done.

Oh, and dump your cable TV service. Get the shows you actually enjoy from iTunes and Netflix and stop wasting time watching whatever’s “on”.

What’s your favorite thing to do when you’re not being an engineer?

I love to write. Not anything substantial, like novels or stories — just blog posts. Writing about a subject helps clarify, mature, and sometimes even change my opinion on a topic. Afterward, I feel accomplished and productive, and the responses I get are fulfilling, constructive, and often more numerous than I expect.