API First, Mobile Second Development

Web applications used to get developed Web First, with mobile treated as a secondary after thought; something to be handled by clumsily redirecting mobile users to m.yoursite.com which offered stripped down functionality and larger buttons.  That was a mistake then, and it's a bigger mistake now. The reaction to this has been the rise of Mobile First web design.  If you google "Mobile First" you'll find roughly a million articles discussing a new approach, in which the mobile application is the primary target, and the wider web is treated as secondary.  It's better than the status quo, but it misses an even bigger opportunity.

That bigger opportunity is API first application development.  API first development demands that you define what your application does early, but not how that functionality is presented.  The same API is then consumed and exposed by your native mobile app, your websites, and other clients.

API first development makes it easier to integrate your application into other systems.  It can make it so that it's not just possible, but it's simple to integrate the functionality you've created into third-party applications, enterprise workflows.  This dramatically decreases the costs of collaboration, supporting relationships and integrations that would otherwise be infeasible, expanding the aperture on your biz dev capabilities.

Don't get me wrong, Mobile First is certainly better than Web first/Mobile Second.  But API First is often the best path forward for interesting applications, as it allows your application's capabilities to be composed in a broad and valuable multitude of ways.