We'd been building iPhone apps for two years by then. When we started the company, hardly anyone was interested in making apps, and we took whatever came in. For the first six months, we never once took a project that ran more than three weeks. One of them we finished in three days flat.
Let's make an app for that
Everything changed in late 2009. Almost everybody wanted an iPhone app, and for the first time we had more requests than we could handle. The first-come-first-served approach we'd been running had to go. I remember watching a genuinely cool project walk away because we didn't have the bandwidth to take it, and it bothered me enough that we decided to get picky about who we worked with.
Getting picky with clients turned out to be harder than it sounds. There's no real way to tell how a client relationship will play out before the project starts, so something that looked exciting in the pitch could feel completely different two months in. So instead of relying on gut feel, we built a framework: was it a startup or not, did we think the product would actually do well, and what kind of work did this specific company usually send our way.
Most services companies obsess over what the client thought of them. I cared more about what my team thought of the client. That distinction mattered less for a product company, but for a services firm putting six months of real effort into someone else's product, it mattered a lot. The client paying on time was never the same thing as the client being worth working for.
Nothing kills the team's morale more than an uptight client.
After working with clients from across the globe, and a fair amount of internal argument, we settled on a framework for rating clients before we ever started the work. It wasn't built to be universal. It was built for us, but the three questions underneath it held up well enough that I still think in these terms now.
How important is it for them?
The first question was how important the project actually was to the client. Internal software that a team would have to be forced to use was an automatic no. A startup was almost always important by definition, and from there we scored it up or down: two founders scored well, three scored lower, five or more scored badly. A founder who had actually left a job to do this scored higher. A technical founder who could answer our questions directly scored higher. A founder with real marketing chops scored higher still. Two founders with strong resumes who'd both walked away from stable jobs was about as good as it got. For a large company, the only thing that saved the score was knowing the person who hired us would actually stick around, because for most big companies, nothing mattered more to the people in the room than their lunch break. We did meet exceptions, but they were rare enough that I still remember them.
For most big companies, nothing mattered more to the people in the room than their lunch break.
Will it scale?
The second question was whether the client could actually scale what we'd build for them. This one was harder to game, and sometimes even a client who did everything right still didn't make it. That was just how it went. What we could rate was decisiveness, which turned out to be the single most useful trait we tracked, and it got worse the more founders there were. The way we tested for it was to get every founder on a call together and ask something small and answerable on the spot, like whether one minor feature in the spec was worth keeping. The answer itself didn't matter much. What we were watching was how long it took to get one, and who in the room actually gave it. Whoever answered fastest was the person we wanted talking to us from then on. If nobody stepped up, that told us something about everything that would come after.
What stage are they in?
The third question was how far along the client actually was in their own process: wireframes done, APIs ready, content in progress. This mattered because we were, at the end of the day, a services company. Our job was to build something real and get it to market fast, and a client wasn't going to give us good feedback if we missed the date we'd promised, even when the delay was entirely their fault. So it became our job to tell them what they needed to have ready before we'd start. No wireframes usually meant a 4-16 week wait, and we'd just tell them to come back later. Rough wireframes meant we'd start the conversation, but we were explicit that this was preparation, not development, and that finalizing them would take another 2-4 weeks. APIs were the real test: unbuilt or undocumented APIs meant we'd end up debugging their bugs on top of our own, so wherever some were already there, we pushed hard to get the rest finished before committing to a timeline, and we tested every endpoint ourselves to see how stable it actually was. A client's attention to detail always showed up in that first week, which is why we kept the option open to walk away that early if it wasn't working out.
There were a few other signals we tracked, but these three did most of the work. If a client cleared them, we'd introduce them to the team and let people decide for themselves whether they wanted to take it on. If the team said no, we'd help the client find someone else rather than drag out a bad fit.
Wrapping up
Looking back, the time we put into this framework paid for itself many times over. Three of the startups we picked this way went on to become companies people would now call unicorns, and one of them ended up acquiring us a few years later, which is its own story.
This is not something to be left to chance.