APIs as MVP?!
I still remember the birth of IaaS (infrastructure-as-a-service) when Amazon launched EC2, the “Elastic Compute Cloud”. At that time Amazon Webservices was all about APIs. You needed to make API calls for everything. There was no AWS console, you could only sign up through the web and that was all there was. If you didn’t want to use the command line to provision servers or build your own API client or integration to manage them the pretty much only available tool of choice was Elasticfox, an unofficial Firefox browser extension that provided a visual user interface to EC2.
Today, of course, it’s different. Whenever Amazon releases a new service it is added to the AWS console, a web-based interface for managing resources on the Amazon cloud. They are a different company now and have the resources and processes now that they didn’t have back then. But for some of the more advanced AWS features or specialized settings they are still following a release cycle of API and CLI first and Web UI second.
The software development methodology du jour is agile. The business side talks about building lean startups and MVPs (minimum viable products). Everybody wants to iterate fast and quickly see results, get feedback from the market and be able to change the product if necessary. In this environment, who would want to waste time building something that nobody wants?!
Another aspect of software development today is that it’s API-driven. Traditional web applications that render a page on the server are becoming increasingly rare and are replaced by SPAs (single-page-applications) in the browser and native or hybrid mobile apps; the concerns of UI and UX design are delegated to the client and the server typically offers JSON-structured data in a RESTful manner.
If you consider these two aspects, agile and API-driven, it is obvious that the API - which is designed and built first - is a candidate for an MVP. Not for everyone, of course, but if your target audience is developers and other technical staff (the “nerds”, so to speak) they will feel comfortable copying & pasting some code to the terminal or into a generic API client such as Postman and changing the parameters according to their needs. They don’t need a fancy UI for everything. I wouldn’t even be surprised if some of them might appreciate what you built even more this way due to some kind of IKEA effect. And if they find a feature useful you can invest into a nice visual UI for it as part of your next sprint with confidence.
At CloudObjects we plan to use APIs and command line interfaces as MVPs for product launches for all the reasons mentioned above. This does not mean that we don’t appreciate a well-designed visual interface, it’s just that we fully believe in the lean startup approach and want to build for people who love to get their hands dirty (metaphorically speaking, obviously) first and later expand to be more inclusive for non-technical audiences to leverage the power of APIs and the cloud.
Want to chime in on this topic? Just leave a comment below!