After 6 years working on developer experiences, these are my rules of thumb for building a business on APIs: 1. Don't build a business on APIs 2. Don't be Creative 3. Treat Customers like (Your) Children 4. Do Fewer Things 5. Focus on the Docs Nobody Reads 6. Sweat the Small Stuff

1. Strange but True
Counterintuitive Paths to Building a Business on APIs
Thomas Bouldin
Software Engineer
Parse+Facebook
@inlined
The first strange thing about this talk is probably the speaker. You may notice that I’m a Software Engineer. I’m not a founder. I’m not in sales or marketing, so I’m not in
the type of role typically tasked with building an entire business. So why am I here in front of you today? Well, I’ve been around the block for a while and I think my view
from the trenches has something to offer.
I normally give talks which are a bit more focused on dry technical details of a platform, so this touchy feely stuffy is a bit new to me. Forgive me if I’m a bit gruff. I don’t
intend to get all touchy feely without reason. I’m not some secret BA in fine arts trying to justify their way into a tech conference. Most of my career has been focused on
building developer experiences. Before my time at Parse and Facebook, I also spent years working on Microsoft’s Windows Developer Platform.
Windows is an institution; it’s lasted longer than many of our best practices. The never-ending process of modernizing a developer platform is tricky business, and when
you have keeping a millions of users and billions in revenue, you adjust that business very carefully. I always wondered, however, what it would be like to start from
scratch. What we could do were we to disrupt an industry rather than cultivate it? In 2012 I seized this chance and joined a little known startup called Parse.

2. TL;DR:
Building a business on
APIs requires as much
psychology as
technology
I’m not going to hold you in suspense; in case you’re waiting for some debate about the best stack to run a business on, that’s not what I’m here for. I couldn’t give a
crap about what technology you use if you’re not using it to best serve your customers. Building business on APIs requires as much psychology as technology; the key
trick is empathy.

3. PHYSICAL SERVERS
LOAD BALANCING
DATABASE BINDINGS
RESTful API
ROUTING
MIDDLEWARE
APP SECURITY
APP BUSINESS LOGIC
NETWORKING
CACHING
DATA MODELS
USER SESSIONS
SOCIAL
PUSH NOTIFICATIONS
FILES
UI BINDINGS
Parse+Facebook
Parse’s idea was simple and compelling: Rather than spinning up servers, managing databases, building auth layers, planning scaling and failover
scenarios, and writing networking code, we provide and SDK for a turnkey backend ready to host your apps. We replace complex infrastructure with APIs.
Look at the world we lived in a few years ago: if you wanted to build a cloud connected app, you had so much foundation to build before even starting. You
provisioned servers; planned a network topology; managed databases; built your own security layer; networking API; caching; mapped it to data models; and
had to build advanced features like push notifications, file management, and UI bindings from scratch.

4. PHYSICAL SERVERS
LOAD BALANCING
DATABASE BINDINGS
RESTful API
ROUTING
MIDDLEWARE
APP SECURITY
APP BUSINESS LOGIC
NETWORKING
CACHING
DATA MODELS
USER SESSIONS
SOCIAL
PUSH NOTIFICATIONS
FILES
UI BINDINGS
YOUR APP
Parse+Facebook
All of this was before you could even get to your app; the thing that actually matters: engaging UI, useful functionality, unique content. These are the things
that make you stand out amongst the sea of apps out there, and so it’s the thing you should be focused on; where all your time should go. Nobody is going to
recommend your app based on how your data model spans Objective-C, Java, and C#, so Parse had a great idea.

5. PARSE
YOUR APP
Parse+Facebook
Focus on the part that matters (ingenious, right?). We give you the building blocks you need to build great cross-platform apps that delight people without
reinventing the wheel. We had a great opportunity to revolutionize the way people build apps.
Our core cultural value is customer empathy. We focus on a creating a terse and comprehensible SDK that’s intuitive, well documented, and well targeted to
our audience. These values have paid off. In 2013, Parse joined Facebook as part of the Facebook Developer Platform. With Parse’s empathy and
Facebook’s reach, the platform has caught fire. We now provide the backend for some of the top brands like Samsung, Groupon, VEVO, mobigame,
Sesame Street, and the White House. Over 500,000 apps have been built on Parse and we serve billions of API requests each month.

6. Parse+Facebook
We provide this service across all the major platforms. Parse is available on Mobile (iOS, Android, Windows Phone), Desktop (Windows, and OS X), and
Web as both Front End and Back End technologies. We also document the REST protocol with which you can talk to our backend, which enables
developers to support Parse in languages and environments before we do. If you’re going Android to iOS, or vice versa. You might even be using a cross
platform tool like Unity to build on iOS, Android, and Facebook Canvas—our games platform.
This experience delivering a loved service across a wide variety of platforms has been an excellent learning opportunity. We’ve learned a lot about
building a business on APIs.

7. What did we learn?
(A Cynic’s Guide to building a business on APIs)
After three years and countless platforms, I’ve become a bit of a cynic. Sometimes people make mistakes that just feel so obvious in retrospect. So I’ve agreed to share
our secret sauce, but I haven’t agreed to sugar coat it. So what did we learn?

8. How to build a business on APIs:
1. Don’t build a business on APIs
2. Don’t be Creative
3. Treat Customers like (Your) Children
4. Do Fewer Things
5. Focus on the Docs that Nobody Reads
6. Sweat the Small Stuff
Not the cheeriest list, but one I’d advocate nonetheless. I think if you give me a chance to explain, they actually make sense.

9. 1. Don’t Build a Business on APIs
So rule #1 for building a business on APIs? Don’t.
The API is never the product; the product is the service your API provides. A company which brags about its APIs is like a restaurant which brags about its oven: passion
for your craft is a good thing, but it’s not the point.
Consider the optometrist. Optometrists compete with each other for the latest styles of glasses, but this all comes after the assumed benefit of fixing your vision. VISION
is the service an optometrist provides; the major breakthroughs in glasses get them out of the way. The best glasses are the ones which are most transparent (pun
intended).
Your API is not the product, it’s the medium. Learning an API has a real cost for your customers, so you should focus on reducing that cost. Your product is a service
provided to a developer and their customers; remember to serve them. This isn’t an art, it’s the service industry.

10. 1. Don’t Build a Business on APIs
controller.parseClassName =
PFUser.parseClassName;
controller.textKey = @“username”;
controller.imageKey = @“avatar”;
Let’s look at a way Parse tries to be transparent. Imagine you’re trying to table view in iOS which displays all your app’s users by username with an icon for their avatar
next to the username. You need to map a User’s data to an entry in the table, download their icon, caching both user info and icons in memory and on disk, and
implement drag to refresh. This is how you would do that with Parse. This code is terse and focused on the specialized task of mapping cloud based data to a UI. It
handles all our complex requirements with three lines of code! The API is staying out of your way and letting you focus on the task at hand, not the technologies
necessary to accomplish it.
What about other great examples of APIs that just get out of the way and provide a service? Twilio makes it painless to interact with SMS or voice calls. Transcending
“apps” and reaching feature phones is a magical experience, largely because using Twilio’s API wraps up their business of telephony infrastructure into something almost
transparent. And Stripe: their business is handling money and monetary regulations. They don’t just talk to major credit providers, they handle all parts of your business
necessary to avoid being subject to legal oversight like Sarbanes Oxley. You focus on growing your business and they handle regulations and security.

11. 2. Don’t be Creative
“You’re so vain
You probably think this
song is about you”
—Carly Simon
Part of being a transparent service is understanding your place in your customer’s workflow. When you build a service focused on your product you think about your
offering in a bubble. When you focus on your customer’s needs instead, you understand your place in their workflow. Remember, this is a service industry. It’s not about
you; you don’t need to be a unique little snowflake.
Customers will approach your software with a background steeped in all the other software they’re used to. If you feel familiar to that background, you will be easily
adopted. Similarly, if your product is consistent, it will be more easily adopted. Be very strict about internal consistency within your product, including naming
conventions, grammar, etc. Also be sure you fit in natively into the environment which your product serves.
Fitting in naturally means you’ll include fewer (new) dependencies for your customer. You’ll also require less training to be incorporated in your solution. All of these lower
the friction to your API (and your business) being adopted.

12. 2. Don’t be Creative
str_repeat
strcmp
str_split
strlen
str_word_count
strrev
When naming your APIs, err on the side of boring, not terse. Be internally consistent, even if this might conflict with your environment. In PHP, the authors chose to be
consistent with C APIs where a counterpart existed but to be consistent with PHP conventions otherwise. The result is a confusing mess:

13. 2. Don’t be Creative
void object.save()
Task<Void> object.saveInBackground()
void object.saveInBackground(SaveCallback)
void object.fetch()
Task<T> object.fetchInBackground()
void object.fetchInBackground(GetCallback<T>)
The Parse API is internally consistent. It’s boring. It’s descriptive. You know exactly what what fetchInBackground is going got do. You learn very quickly that all methods
have an InBackground equivalent you should prefer. All methods can either take a callback or return a task. This predictability means developers can intuit your tool; they
spend less energy remembering your quirks and more energy getting stuff done.
Some great examples of dull simplicity: JSON+REST+HTTPS. It’s secure, it’s predictable, and the industry loves it. It may not always make sense to follow industry
dogma—even Parse isn’t fully RESTful—but if you’re going to break from the industry trends, try to at lear be consistent with yourself. It’s weird, for example, when a
company uses JSON for their authentication service and XML for their other APIs.
Dull design—aka “consistency”—has been a driving force in much of the cloud revolution. RESTful API were more easily developed by high-level tools like Ruby on Rails.
They could be mapped more consistently to client code. Now that consistency is giving rise to meta-services and aggregators like IFTT and Mashape.

14. 3. Treat Customers like (Your) Children
Treat customers like your children. That doesn’t mean you should belittle them; who actually goes around belittling children?! Treat them the way you would treat your
actual children:
• Invest in their success because their success is your success. It’s really important to reduce the number of ways your customers incentives and yours can be
misaligned. At Parse we try to highlight customer case studies. We also try to be upfront about our limitations and use pricing to incentivize customers to design
software we can better support (e.g. last year we transitioned from charging based on overall API usage to a much more gracious peak traffic model since this better
reflected our true limitations)
• Anticipate their needs and provide an environment in which they can grow. Think about how the product feels for a beginner and focus on quick start guides. These
guides should reach a checkpoint that validates the customer is successful early and often. For example, our quick start guides for data let you know when you’ve
successfully registered an object. Our quick start guide for Push lets you send a push which will be received on any successful device.

15. 3. Treat Customers like (Your) Children
• Consider the advanced developers. Pick a few types of sophisticated users and build optional complexity along their learning curve. Though your API should have
opinionated defaults that keep things simple for the majority of users (esp. novices), it should be flexible enough for sophisticated users to extend. Sometimes this
means open sourcing part of your product, but that can also be a sign of laziness. It makes sense in cases such as a UI library where the valid configurations are
limitless, but other APIs can be just as powerful and much more approachable if designed to be flexible.
• Warn them if they are in danger of making a mistake, but don’t stifle creativity. The golden road is a support structure, not a prison. For example, it’s almost always a
mistake to make a network call that blocks the UI. Parse will detect this, warn you, and even let you set a breakpoint to catch this behavior, but we don’t stop the
developer. Maybe they just wanted to hack something together or it makes unit tests easier to build?
• Don’t lie to your children. Don’t make promises you can’t keep.

16. 4. Do Fewer Things
“Deciding what
not to do is just as
important as
deciding what to
do.”
—Steve Jobs
Now that you’re being a parent, you’ll have less time on your hands. Do fewer things. Offer fewer features so that what is left tells a cohesive story. Understand your
product at many technical level of detail: at the top level you should offer 1-5 things. Each of those things can have a small number of features with an approachable
learning curve. While you should offer enough sophistication to satisfy the power-user, your product should be easy for the first-time user. At Parse we specifically
consider what we call “wedge features”, things which must have no conceptual dependency on any other product because we want new customers to be able to use
them as their first/only investment in Parse. These “wedge features” have synergy with other features but their basic use case must be fiercely guarded as isolated.

17. 4. Do Fewer Things
If a company offers too many products, it’s hard to guide a new user. Looking at this product listing, I’m not even sure which technologies I’ll need to solve my problem or
how they interact with each other.

18. 4. Do Fewer Things
Parse however offers three unique pillars and customer knows where to look when they’re starting with Parse: Are they looking for a “cloud”, push notifications, or
analytics? Each of these products is conceptually standalone, even if they leverage each other under the covers.

19. 4. Do Fewer Things
Similar to narrowing your feature set, focusing on a narrower audience helps you provide better support.
Consider a chef’s utility knife and a swiss army knife. Swiss army knives are fantastic utilitarian devices, but they appeal to a niche market for portable utility. You’ll rarely
see a swiss army knife in a kitchen drawer; it belongs in a pocket. Similarly a chef’s knife is much more efficient for preparing food in a kitchen. You’ll rarely see a chef’s
knife in a backpack; it belongs in a kitchen block. REI doesn’t carry a Swiss Army Chef’s Utility Knife because it doesn’t make sense to combine these two niche markets
even though both tools accomplish the task of “cutting things.”
Going back to Parse’s 3 pillars, how do we know we’re not making a Swiss Army Chef’s Utility Knife? Start with a core product and build sophistication to it. Strike out
with a new wedge feature if it can be both useful as a standalone product and has a market advantage that only you can provide (due to your other wedge features).
Parse Core provides basic data services without any other dependencies. Parse Push is conceptually distinct. And advanced users know how Parse Push is built on top
of Parse Core so it can use the same level of sophistication in Parse Core to segment their audiences in Parse Push. Similarly, Analytics may seem completely disjoint
from the other two, but when you add usage analytics for Parse core or A/B testing for Parse Push, suddenly Parse Core, Push, and Analytics are worth more than the
sum of their parts.

20. 4. Do Fewer Things
Even within a specific niche, varying levels of sophistication in your customers’ needs will require varying levels of complexity in your product. API designs, tutorials, etc.
should focus on the simplest use case that will solve the majority of customer’s needs. The 80-20 rule (or Pareto principle) suggests that 80% of your customers will be
satisfied with 20% of your grand vision. Release your first version when you think you’ve solved a good number of people’s problems, not when you think you’ve solved
all of them. Take their feedback; see which of the remaining features are most important to potential customers.
Remember that the API is the medium, not the product. Remember that an API has a cost. If you try to serve everyone, then everyone you serve incurs the cost of
learning a more complex product. Branch out into new areas which have natural synergy with your existing product. Add complexity to your system in a way that is
optional and keep it out of your quick start guides.

21. 5. Focus on the docs that nobody reads
“If you don’t know
where you’re going,
any road will get
you there”
—Lewis Carroll
With less time available to do fewer things, your first priority should obviously be the documentation that nobody is going to read anyway. Documenting software is like
measuring lumber: it’s best done before the cut. You might want to do some finishing touches, but in the words of Lewis Carroll, “If you don’t know where you’re going,
any road will get you there.” Build documentation for your feature before you implement it. I call this “Demo Driven Development”, which is an extension of “Test Driven
Development.”
Play with your potential product before its design is fixed and see how it feels; this lets you find design flaws early when they’re cheapest to correct. My rule of thumb
when beta testing a potential API: a demo should reach its punchline in 3LOC or less. If you need to write too much boilerplate to set up the punchline, then your product
may need to be more decisive and serve the 80% audience better with its defaults. As a contrasting rule, watch out for too much happening under the covers. “Magic” is
a bad word in API design. The implementation of an API should be easily understood; this allows the sophisticated user to grow into advanced use cases because they
intuit the way your API works and can extend it.
Carefully planned documentation will also do a fantastic job at exposing conceptual dependencies in your product. How many concepts are necessary to create a push
notification natively in Android? You need to understand the Android Manifest, GCM service, Intents (Pending Intents, broadcast Intents, and Intent security), the tradeoffs
between Broadcast Receivers and Intent Services, Notifications, etc. And that’s just HANDLING the push, not registering or targeting. With Parse you can worry about
those if you want (and there’s advanced tutorials on the subject) but your minimum requirement for handling push is to paste in a few lines in your manifest.

22. 6. Sweat the Small Stuff
“A stitch in time
saves nine”
—Unknown
Another benefit of Demo Driven Development is that it helps you avoid cutting corners. By putting qualitative work before quantitative, you ensure you can do a good job
before running out of steam. This helps you spend less energy asking yourself whether you’re ready to release a product as it nears its target. This helps you avoid falling
behind in technical debt. A hard to use API or poor documentation will leave you trapped in recurring customer support debt at best and out of business at worst.
Spending time to learn your customers’ needs will help you build better products. This is why our Parse developers takes turns spending a week on-point to handle
customer support across broad product areas. By helping out with customers support we feel their pain and it helps inspire or prioritize the features we build.
We maximize our time to develop these features by keeping our technical and support debt manageable. We spend a day each month looking at ways to improve
documentation outside of our product cycles. And each month we recognize the Parsers who have tackled the most technical debt and who have contributed the most
to customer satisfaction.

23. How to build a business on APIs:
1. Don’t build a business on APIs
2. Don’t be Creative
3. Treat Customers like (Your) Children
4. Do Fewer Things
5. Focus on the Docs that Nobody Reads
6. Sweat the Small Stuff
So to recap, here is my advice for building a business on APIs:
1. Don’t build a business on APIs; build a business on a service. The API is the medium, not the product
2. Don’t be creative, because it’s not about you. Fit naturally into your customers’ workflows
3. Treat customers like your children. Invest in their success and design your product around a learning curve.
4. Do fewer things so that your product can be mentally cohesive. When you create advanced features, put them in advanced guides. And remember you can’t help
everyone. It’s better to give 100 customers a spectacular experience than 200 customers a shoddy one.
5. Focus on the documentation, even if nobody reads it. By starting with your finished product, you’ll discover problems early and fix them cheaply. Your customers’
ability to learn your product is a core part of its value proposition, so focus on the learning curve early and often.
6. Sweat the Small Stuff. Keep ahead of technical debt and customer education. The more you invest in a sustainable support system, the more time you will have to
innovate.
What’s the underlying theme to these rules? Empathy. Service. These aren’t secrets for building a business on APIs, they’re just good advice for building a business
period. Remember, this isn’t an art; it’s the service industry and the customer comes first.