A No Stack Workweek Playbook – Examples of API-Driven Business Opportunities
How would you, in practice, combine multiple APIs and a ”last mile” user experience to deliver added value while minimizing need for tech-heavy development work? That is the question I’m going to be exploring in this blog post.
In my previous post, I combined several concepts into what I call the ”No Stack Workweek.” The name comes from an earlier concept called the ”No Stack Startup,” but I wanted to make a distinction between a startup (which is typically growth-oriented and often VC-funded) and a cash-cow business that enables a ”4 Hour Workweek” (a concept developed by Tim Ferriss in his book of the same name). Check out that previous post if you’re interested in how I came up with my combination of these concepts.
Building a business is kind of like juggling and driving a unicycle at the same time – an interplay of multiple stakeholders and the machinery of processes (which are sometimes invisible) that enables the simultaneous delivery and capture of value.
Building this machinery is usually expensive and time consuming. An entire movement called “lean startup” is trying to explore how to minimize up-front building. The goal is to ensure that if a business doesn’t take off as envisioned, the waste of resources is minimal. However, lean-startup thinking usually isn’t focused on the lower-level engineering-related steps one could take to minimize the build process. Rather, it's focused on avoiding building at all. It utilizes techniques such as using landing pages to test interest (smoke testing) or delivering value manually (concierge MVP) before building anything.
Additionally, discovering lucrative business opportunities and executing them is hard. It is not easy to deliver and capture value in real markets of real people, especially in a niche that's accessible to a new player within a given window in time. If it were easy, everyone would be an entrepreneur working for themselves.
The “No Stack Way” reduces the need to invest in basic infrastructure
What I like in the “No Stack Startup” approach is that you pay other companies to maintain APIs that create value for both you and your end-customer. That way, you don’t have to care about stuff other companies can do for you, stuff that is getting quickly commoditized, anyway. The easy examples include Amazon AWS or Heroku for handling server infrastructure, Twilio for SMS and voice infrastructure, Stripe for credit card processing online, or Square at the point-of-sale.
Even before anyone used the term “startup,” banks had always been securing financial transactions for new businesses, accountants and lawyers had been handling the paperwork, and so on. The difference today is that you can use programmatic interfaces (APIs) to automate all of those tasks so that no humans need to be involved in repetitive “infrastructuresque” chores. These tasks are necessary, yet they are commodities. That is, they are hygiene parts of the value creation/capture process that produce little or no competitive edge.
So how could we build an entire business almost entirely using other companies’ APIs to assemble a value-creation-and-capture machine that requires a minimal amount of coding effort?
How would you deliver a package via APIs?
Beyond using the obvious APIs from companies like Amazon AWS, Twilio and Stripe, at first I draw a blank when it comes to whole end-to-end architectures.
Let’s say we’d want to automate end-to-end delivery of postal packages. I'm not saying that would be a great business opportunity at this point, but let's assess whether or not we could do it the "no stack way." Do we have a company that offers an API without minimum volume limitations or a requirement for long-term contracts to ship packages? Does that API include tracking of packages to make the user experience smooth? How would I know?
When I search for “package delivery API,” the first results include a company called EasyPost, which seems to be exactly what I’m looking for. The search also returns multiple articles from Programmable Web (PW), which is a site specializing in listing APIs, and 92 of them are related to shipping. However, PW’s listings are very qualitative, and comparing the APIs seems to be somewhat “apples and oranges.” It would require quite some investigation effort to determine which of the 92 APIs actually are suitable for our hypothetical business. The same goes for EasyPost. How do I know if it is actually a good service for this use case?
A playbook for “no stack” businesses?
What if there were a playbook of tested-out “plays” of different stacks working together? More than just a list of APIs, such a playbook would also include some thoughts on how the APIs fit together, how pleasurable they are to use, and how their pricing works for very small businesses. PW could be a great source of discovery of new APIs, but the value of a playbook would be in more than just the technical aspects of an API and a technical proof of concept. As they say, the devil is in the details, and only by testing a service (not just the API) in the context of an actual business process can you learn enough about its properties.
This would obviously require lifting the kimono, as they say, regarding the business and technical architecture of a company, which is something entrepreneurs often aren’t willing to do. Often when we read about the “stacks” of companies such as Uber (https://eng.uber.com/tech-stack-part-one/), for example, the descriptions are so high-level that they don’t easily allow us to understand exactly how the different pieces have been glued together and how well they actually work.
Hardware DIY sites already provide playbooks for DIY enthusiasts
An analogue here, much more fitting than PW, could be hardware DIY project sites such as Hackster.io (https://www.hackster.io/arduino/projects) or DIYhacking.com (http://diyhacking.com/diy-projects/arduino-projects/).
Both of these DIY sites have a familiar format for project descriptions that start with an interesting use case (an analog for our concept would be a business case). The sites then go on to show what parts are needed (a list of APIs in our case) and demonstrate how the project was completed. Most importantly, the sites discuss how the different parts were combined, including what needs to be taken into account for the components to work well together. Such a discussion might also include the different alternatives that were tried in the process, and why the choice was made to use a specific component instead of another in the same category. This sort of discussion is what’s missing from PW.
Making it as easy as drag-and-drop
The playbook could even use a visualization technique similar to popular drag-and-drop programming environments such as MIT’s Scratch (https://scratch.mit.edu/), Google’s Blockly (https://developers.google.com/blockly/) or Berkeley Snap! (http://snap.berkeley.edu/). By creating connector nodes similar to the way that Zapier (https://zapier.com/) works, an integration of two APIs would need to be created only once, and afterwards people using those APIs together could avoid programming entirely.
This combination of a business case and a technical end-to-end implementation guide (or even prefabricated sample projects) would make assessing the suitability of APIs much easier, since instead of reading through the sales materials of the API provider, one could directly get a first-hand account of how the API actually worked in a real-life scenario.
Playbooks for reducing business “boilerplate” and increasing innovation
This way, when building a new business, one could more easily discover new APIs suitable for the situation, as well as get help in the actual implementation. Most of the startup's work could then go into the unique aspects of the business, instead of the setup of what is known in programming as “boilerplate."
When reading other peoples’ showcases, it’s much easier to be “creative” when you have stencils that you can combine, instead of facing a blank slate. Since transferring a business model that's working in one geographic market to another market is already the business of many companies, there isn’t really anything dramatic in this kind of copying and pasting, except that the actual implementation would be much cheaper. Many business ideas that would otherwise be left in the heads of up-and-coming entrepreneurs due to lack of build resources might now get built and delivered to market, and that would benefit the end-customer.
Do you have a budding idea for a combination of APIs that could form an end-to-end business already? Do you feel like sharing it?
Let me know on Twitter, @therttua – and let’s talk more!