A small alternative for full API-first (centric) approach

I am a big fan of API-first architectures. I am thinking of building another system based on this idea. Where I have in the past coupled my website to a HTTP request class to my own API (using HMVC avoiding real HTTP overhead). I am now thinking whether an alternative approach might be better in architecture eye aspect. Questioning my develop ideas and methods.

semi API-first (the alternative)

    Admin    
          ↘
Website → Service (gateway) → Core Domain (Repositories etc)           
          ↗
App → API 

The idea about this is that my Services will be created using simple 1 argument methods. Just like an API. Whenever there is a need for an API, the API controllers will be created and mapped to the Services the website is also using.

Pro

• No extra layer for website (no API client which consumes HTTP protocol)
• Can still create clean API when Service is designed as an API in mind (just map API controller to Service)

Con

• Need to create API lateron each time when asked for (which means planning development which could be avoided)
• Because the website is no client of the HTTP API, it will be less "production" tested (e.g. no: see it works! Our own website works).

API-first

      Admin → Service (gateway) → Core Domain (Repositories etc)
              ↗
Website → API
         ↗
      App

Pro

• Always API for all website functionalities :) Fully tested! Website works on it
• Can easily separate website by using HTTP instead of internal requests. Even create in total different programming language
• A out of the box solution ready for the first real external consumer. Better planning of development.

Con

• Bit more code needed for website (Website → API Client → API)
• Alot of API endpoints which may never be used but code will be there to couple to Services

Conclusion

The first (alternative) approach seems to be part of the bigger plan. The full API-Centric (second) approach is just an extra layer for the extra ease for a ready to use API from day 1. Which is very nice and never a bad idea.

In my eyes both scenarios I can't go wrong. Full API-First feels the way to go to prevent any extra development in hasty moments. But it might be overkill if there won't be much consuming afterall.

Which would you prefer? Go all the way from the start and be 100% ready for possible consumers? Or go with bit less development time and then create the API endpoints or refactor the project fully in api-centric design?

I guess there's no "right" answer for this question. But if there's an expert out there. Please let me know your thoughts on these architectures! Thanks!