APIs are a Contract which Startups Constantly Renegotiate
One of the key value propositions of web startups is an application programming interface (API) or a read/write interface. If you're a fellow follower of AVC you're already intimately familiar with this message which Fred Wilson periodically hammers home. Businesses such as Twilio have gone so far as to make their core value offering a powerful yet easy to use API to phone networks. Beyond the technical interface, startups support business interfaces which include leadership, investors, partnerships, and customer service. In this riff I'll explore why startups alter their public interface and follow that up with the corresponding burden early users (adopters + customers) are forced to bare.
What goes on inside early companies?
Startups are high energy boiler rooms (plasma chambers) which are forced to grow and adapt to changing markets in order to survive. They are the crossroads between demand, inspiration, implementation, and restricted resources. The credo of learn by failing* is an integral part of early business life. Tremendous internal pressures and deadlines combined with a dynamic team roster^ result in practical direction shifts. The likely causes for company instability are:
- social issues between team members. Who's in charge, communicating expectations and living up to them. Team roles evolve, and core members move on
- redesigning the product with focus on inherent virility. Polishing the user interface and distinctive value offering
- adjustments to the business model
One or more of these root motives result in an undulating public surface for startups. But these aren't excuses for unresponsiveness or unreasonable downtimes. The business interface is fulfilled by leaders who step up when they're needed. I'm Sparticus is the hallmark of any founder or team member when it comes to claiming responsibility and making sure customers and users walk away satisfied.
http://www.youtube.com/watch?v=-8h_v_our_Q
This is the age old dilemma of platform developers around the world:
to build or not to build?
The gamble on incorporating an API or building on a platform is almost certainly not going to be a one time investment of time and resources. A choice to adopt a startup's API is one that will cost your company time to support each time changes are made by the remote platform. Companies who embrace open standards and protocols (http & pubsubhubbub vs. application specific interfaces) can mitigate the technical tax of dynamic APIs by limiting support time from partners.
Notes:
*= Mark Suster is on a roll with two recent posts which relay the bitter taste of failure first hand, and how he embraced his mistakes to learn from them. Embrace your Losses -they will make you stronger and You're most vulnerable right after you've won.
^= dynamic team roles: Who is in charge of the company (ceo/investors/founders)? Who is responsible for the technology (CTO/VP engineering)? Who is in charge of the product (CEO/President/Product Lead)?
If there's one constant in startups it's change, organization and team are no exception.