API-first development means designing and agreeing the interface before writing the implementation behind it. The objection is consistent: it is slower, and we only have one application to serve.

Both parts of that objection are true at the start and stop being true fairly quickly. The second application arrives sooner than anyone expects — a mobile app, a partner integration, an internal dashboard, a replacement front end.

At that point the question is whether you are adding a consumer to an existing interface or extracting one from a codebase that never had a boundary.

Parallel work. Once the contract is agreed, frontend and backend teams build against the same specification simultaneously instead of one waiting on the other.

Cheap additional clients. A mobile app that consumes an existing, documented API is a build. Extracting an API from an application that assumed a single web front end is a refactor with regression risk attached.

Low-risk redesigns. When presentation is genuinely separate from business logic, changing how something looks does not risk changing what it does. Front-end rewrites stop being frightening.