Making Overcast, Instapaper & Tumblr: A Top Dev Interview With Marco Arment

Welcome to another installment of our Top App Dev Interview series. Each interview in this series focuses on a successful mobile app or game developer and the path they took to get where they are today. Today’s special guest is Marco Arment.

Marco is a prolific technologist, technology writer and podcaster. He is best known for being lead developer and CTO of Tumblr, the sole creator of Instapaper and most recently the sole creator of Overcast, his popular podcast app for iOS.

When he’s not busy programming, Marco is either writing on his website or hosting one of his several podcasts such as the Accidental Tech Podcast (ATP), Top Four and Under the Radar.

Focus

Marco, you’re known for more than one successful project. What criteria do you use when coming up with ideas for projects or businesses?

There’s no reliable method to coming up with successful new projects — I have far more failures and abandoned projects than successes. The only way I know to increase my odds of finding success is to try more ideas.

Knowing when to move on is a tricky balance that I still haven’t mastered, but a good rule is to move on once you’re no longer motivated or able to do great work for a project.

You’re a prolific writer, podcaster and developer. What helps you prioritize what to do and what not to do?

I’m also a father and a lazy procrastinator, so my schedule is all over the place, and I don’t balance the time demands of my projects very well. (Most notably, I’ve barely written anything recently.)

I work in erratic bursts. I’ll accomplish relatively little for maybe a week, then have an incredible marathon in which I accomplish a week’s worth of work in a few hours. In reality, this is how I’ve always worked, even when employed full-time in regular jobs — I just tried to hide it, and my bosses seemed happy enough with the results of the productive bursts to overlook my useless periods.

Nobody should take time-management advice from me. I work this way because it’s the only way I can, not because it’s a good idea. If you have a better work ethic, use it.

If you want to tackle something completely new that you’ve never done before (for example implementing the “Smart Speed” and “Voice Boost” features in Overcast), how do you go about it?

Overcast, Marco’s podcasting app for iOS

Overcast, Marco’s podcasting app for iOS

I often have crazy ideas like those, and I usually just build basic implementations to see if they’re any good, then try using them myself for a while. I’ve always taken a just-build-it approach to design and feature experimentation (rather than formal prototyping or image mockups).

Most of these ideas never see the light of day — not even to beta testers — either because I couldn’t get them to work well, or more often, because they end up being terrible ideas.

But occasionally, they end up being awesome, making it all worth it. This experimentation is by far my favorite part of development. One or two of these crazy ideas can define a product or set it apart from the competition for years.

Indie Development

You’re much more than a developer. You’re also your own product manager, project manager and businessman. How did you develop the non-technical skills you have now?

In today’s hyper-competitive market for people’s attention, every independent developer needs all of those skills, plus more. You can make a fantastic app, technically, but if there are big flaws in its design, marketing, or business model, you won’t get far.

I developed my relatively minimal skills in these areas over time the same way I developed most of my technical skills: out of necessity, at the last minute, while stumbling through, trying to gain as much wisdom as possible from more experienced people along the way.

I’ve been lucky to work with or near many people much smarter than me, from whom I’ve drawn incalculable value. And I practically live in my RSS reader (Remember those? Not dead!), voraciously reading blog posts from people in these fields for over a decade.

For the most part it seems like you are a one-man operation. What do you outsource and what do you keep in-house?

I outsource most icon design, since I’m generally terrible at it, and I hire an accountant for taxes. That’s it.

I’ve outsourced support before, but it’s very difficult to do well, and it’s hard to justify at App Store price levels. So, somewhat controversially, I currently don’t offer technical support and I don’t respond to most email. I set expectations accordingly in the app, and almost everyone is completely fine with that. The percentage of angry people now seems about the same (maybe lower!) than when I had expensive support staff.

What are some of the biggest mistakes to avoid as an indie developer?

By far, the biggest mistake I see indies make is having unrealistic expectations of how much the market will value what they’re making, assuming they can indulge themselves in months or years of fancy construction and consumers will pay for it.

It’s easy to look at successful, painstakingly crafted, impeccably designed apps from well-known developers like Panic or Omni and attribute their success to their craftsmanship, design, and delightful details. Far too many developers believe that if they polish an app to a similar level, they’ll be successful, too. And then they pour months or years of effort into an app that, more often than not, never takes off and can’t sustain that level of effort.

These high-profile success stories didn’t become successful because they invested tons of time or had world-class designs — they became successful because they solved common needs, that people were willing to pay good money for, in areas with relatively little competition. In short, they fit well and were well-timed in the market.

The craftsmanship and design were indulgent luxuries that their successful market fits enabled them to do, not the other way around. Most people buy these apps because they’re useful and necessary, not because they’re pretty.

It’s not enough to make something fancy — it needs to have sufficient value to the market first, which can then fund the fancy design and technical extravagance you want to do if it takes off.