API First, Mobile Second Development

Web applications used to get developed Web First, with mobile treated as an afterthought. Most sites handled mobile by clumsily redirecting those users to m.theirsite.com which offers 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 42,000 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 (desktop/mobile/responsive) websites, and other consumers.

API first development makes it easier to integrate your application into other systems.  It makes it so that it's not just possible, but it's simple to integrate the functionality you've created into third-party applications, and enterprise workflows, unlocking enormous value.  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 modern web applications, as it allows your application's capabilities to be composed in a multitude of ways.