Yesterday at SeatGeek we released a new version of our iOS app that includes iPad support. This was the culmination of months of designing and coding; I’m super-proud of what our team built. Huge credit goes to Matt, James, and Mladen, who led the charge.

When I sat down to wireframe this app, what I thought should be a simple exercise of translating views to a larger screen turned into a big challenge. Creating an iPad UI is hard, I learned—harder than it is for the iPhone [1]. Designing for the iPhone is wonderfully elemental. Imagine if websites had no sidebars—all you saw on a page was the most important, essential content. That’s what it’s like on the iPhone; it makes things easier.

But on the iPad, you have 8x as much screen space to fill. If only core content filled the whole screen on every view, you might end up with some odd-looking views. Consider the “performer” view...

We launched SeatGeek in 2009 at TechCrunch 50 (now renamed “Disrupt”). The elevator pitch was “Farecast for sports and concert tickets.” The site forecasted if ticket prices for an event would rise or fall so that a buyer could time her purchase optimally.

I diligently practiced the pitch. It was be the first time I’d be presenting to so many people. When it came time to present, we saw that Paul Graham would be one of our judges. Great news! We loved Paul Graham’s essays. I got on stage and delivered my spiel. It went pretty well–no major messups. Then time for the Q&A with the judges. We locked up. We’d practiced the pitch, but hadn’t prepared for what they asked us. Graham dismantled us. It was painful. It still is. I just forced myself to watch the video again and my chest now aches.

Afterwards, trying to ease my embarrassment, I wrote a comment on Hacker News and...

We launched SeatGeek’s iPhone app today. I’ve been creating websites for years, but until this project had never made anything native for a phone. As a first-timer, I was struck by some of the differences between web and mobile app design, which I’ll describe below.

First, a caveat: I worked on designing the SeatGeek app but not coding it [1]. What follows is relevant to web/app design more than development.

Designs magically look better on a Retina Display

Retina Displays are rose-colored glasses for Photoshop comps. Take an average design and put it on a Retina Display and it will look above average. Good designs become gorgeous. This discovery makes the whole process more fun. Designing for the Retina Display makes you feel like you have an extra 20% dose of talent. The effect never fully wore off for me; each time I beamed a design from Photoshop to my phone, I was...

When you create a new account, Gmail is blazingly fast. For most users, it stays that way forever. But for a minority of heavy users, Gmail gradually degrades towards slower and more painful speeds. Eventually doing simple tasks like sending an email or archiving a chain is downright glacial. Until a few weeks ago, glacial Gmail was part of my life.

The proximate cause of slowness is mailbox size. The alluring promise Google made when they first launched Gmail–that you never again have to delete any message–is not a reality. If a frequent emailer stops deleting messages, she’ll end up with a slow-as-hell mail app. I spent hours deleting as much of my inbox as I could, particularly emails with large attachements, but was still only able to get down to 11GB (I send a lot of email) [1].

I love Gmail as a mail app. Love the interface, love the shortcuts, love the filters, and lov...

I am a big fan of Sinatra. I love the framework for its simple elegance, but I particularly love it because it’s Rack-compatible, and thus can be easily deployed to Heroku. Both Sinatra and Heroku are geared towards facilitating utter, brain-dead web development simplicity. Pairing them together is the fastest way I’ve found to get a website online.

The Heroku docs for deploying a Sinatra app are excellent, but perhaps make the process more intimidating than necessary for novices, if only because the page includes supplementary info for “pure” Rack apps and other Ruby DSLs. Last week I was helping a friend stick his toe in the water with web development. I wanted to show him how easy it could be to have his own site running on a real live URL. I showed him the Heroku docs, but his response wasn’t “holy shit, this is mind-boggling easy.” Which is a shame, because Sinatra/Heroku...

My co-founders and I have run our startup with religious frugality. When first looking for an office, we found a shared workspace that allowed us pay by the area, and we squeezed in folks for $160/mo per person. When traveling for business, I take the search-Kayak-and-choose-the-cheapest approach to finding a hotel. When hiring, we have a visceral aversion to using recruiters; engaging a recruiter seems like an expression of laziness. This sort of diehard cheapness is not original; there are plenty of startups that are even better at it than us. But recently I’ve been rethinking our approach…

Every person at every company has an implicit hourly rate of value they create for the business. Perhaps Bob, our traveling salesman, provides $150 of value for every hour that he’s working [1]. If Bob catches the flu and is forced to spend a day hunched over a toilet rather on the road...

We recently hired a new office manager at SeatGeek. It’s possible to find good office manager candidates by posting on sites like Craigslist and Monster, but there’s a big signal-to-noise problem–a single Craigslist post can yield hundreds of resumes, many from unqualified applicants. The cost of posting on Craigslist isn’t $25; the true cost is your time.

Many applicants didn’t know anything about our company or the particulars of the job. Perhaps they did a search on Craigslist for “office manager” and applied to every job they found in rapid succession, hoping to get a few hits. These folks reduce the amount of time I can spend with folks who actually want to work at SeatGeek.

So during the past hiring process, I tried something a little unusual: I required that all applicants complete a short Excel challenge when applying [1]. Importantly, the job involves almost no work with...