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 API is then consumed and exposed by your native mobile app,  and your websites.

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 cheap and easy, to integrate the functionality you've created into third-party sites and applications.  This  can dramatically decrease 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.