Lessons Learned Developing the 99designs Tasks API
“Wanna see something cool?”
Two years ago my boss, Lachlan, came to me with a secret side project he'd been hacking on for getting small design tasks done quickly. The idea was for customers to submit a short design brief that would be matched to a designer who's waiting and ready to go.
We assembled a small team and spent the next two months working like crazy to get an initial public release out and prove it was something people wanted.
Lachlan's original vision included the idea of an API for graphic design work along the lines of Amazon's Mechanical Turk—but more beautiful and tailored specifically for graphic design.
We've continued to refine 99designs Tasks as a consumer service, but the vision of an API for graphic design continued to stick in our minds. We just weren’t quite sure if it was worth doing or not.
A Turning Point
Then we were caught by surprise. We discovered that our friends at Segment had built an automated tool using PhantomJS, which screen-scraped our website to work around the fact we hadn’t built an API yet!
I’ll admit—it was pretty embarrassing to be beaten to the punch by a customer on an idea we’d been thinking about for two years. On the other hand, there's probably no better way to validate an idea than to have a customer do it for you.
OK, Let’s Do This
We quickly realized that developing an API would involve more than just the technical design and implementation. The audience and concerns of an API are very different from anything we’d worked on before.
Scoping It Out
One of the first challenges we faced was figuring out what features we wanted in an API. We already had a few API customers that needed a fairly specific feature set for creating tasks—but we wanted to open up the possibilities and allow ideas we hadn’t even begun to think of yet. We made the decision to expand the scope beyond task creation to cover the entire task workflow in order to enable a wider set of possibilities.
Another big question we faced was how to market an API? Our customers are typically entrepreneurs and small businesses. The target audience of an API is very different from what we're used to.
There's a saying that "if you build it, they will come", but I'm not convinced it's quite true. We knew there was some hard work to be done if we wanted to attract developers. There are a few questions that developers might ask when looking at an API:
"Why should I be excited?"
"What are the benefits?"
One strategy we had for attracting developers was to have a collection of compelling examples that would inspire new ideas. The problem is that building these examples requires us to attract developers to build them in the first place. We tackled this chicken/egg problem by working with a group of launch partners in a private beta ahead of our public launch to build some great quality applications that we could show off.
We also applied a "dogfooding" approach at 99designs, where our development team worked on a number of app ideas internally—including a browser extension and a chat bot, all of which used our in-development API.
Part of attracting the best developers means making it super easy for them to get started. There’s a few aspects to this that can help get developers going.
It’s really important to have well written documentation to help developers understand what the API does and how to use it. This means having accurate and up-to-date reference documentation. It also means having plenty of how-to guides, tutorials and code examples.
2. Community and Support
Attracting the best developers also means helping out when they have questions. We’re hoping to foster a community around our API, which will mean some outreach and advocacy. This can include channels like mailing lists, forums and chat. It also means getting the word out and telling developers about your API—like the post you’re reading right now!
It’s important to make our API as familiar to developers as possible, which means following industry standards and trends. We did some investigation into different styles of API (e.g. REST vs RPC)—and what we found surprised us.
One of the RPC libraries we investigated was a library developed by Facebook, called Thrift. We heard out about Thrift from one of our partners that had used it pretty successfully already. We liked the strict data typing and interfaces, and the client and server code generation was quite compelling.
On the other hand, REST is a massive, almost overwhelming industry trend. What we found, though, is that there’s still some debate about how to do REST “properly”. We were a bit surprised that the tools and standards for building REST APIs are still immature and inconsistent in places—even though it’s a far more popular style.
It feels like the industry is suffering a mild case of “Not Invented Here” syndrome. Many REST APIs invent their own custom schemes and headers for things like authentication and request signing, as well as inconsistent use of HTTP verbs and status codes. It seems to be one of those cases where “worse is better”.
Despite the downsides, we decided to go with a REST style, because it’s a style that’s very accessible and easy to get started with, which really counts for a lot.
Supporting an API: the Customer of your Customer is your Customer
In addition to supporting our partner developers, we also need to make sure that our partners can support their own customers effectively. 99designs is pretty obsessive when it comes to customer support. But if customers are using 99designs Tasks via a partner API integration—it’s not really appropriate for us to step in on customers that aren’t ours. However, things go wrong sometimes, so we need to be prepared for problems.
“I need my website redesigned in an hour.”
“This is too much work.”
We have to trust our partners to support their customers how they choose, so we’ve provided tools to help take care of this. In practice, this has meant including webhook event notifications for when customer support needs to get involved.
One of the biggest upcoming challenges is full support for international customers. The challenge begins with language translation and payment in local currencies—all the way through to how we match customers to the designer that's right for them.
If you’re thinking about building a public API for your product, here are five things you should consider:
- There’s more to building an API than building an API.
- Launch partners are your friend.
- Build your API to be as easy to use as possible.
- Problems are more complicated when dealing with customers of customers.
- Be open to imaginative app ideas you weren’t expecting.
We’re really excited for the possibilities that an API for graphic design will enable. We’re currently in private beta. If you’re interested in partnering, please get in touch!