Sounds like a way to artificially pad hours on a project to me.
This obsession people have with "our web app talks to our api" never made sense to me - why are they separate code in the first place? 99% of the difference between a web browser request/response and a web api request/response is down to data serialisation and the view.
It stems from APIs having bugs, and not being consumed by the writers. The flows were badly designed because they would never write a client against the API.
By making the web be a client to the API, the design, quality and maintenance of the API is very much to the fore. It also allows the implementations to evolve at their own speed, which helps a lot with maintenance, especially when one adds a mobile client, or changes some other UX flow... it becomes easier to work through things.
So yes, I agree... slower to get started and 2 codebases. But, so many advantages, higher quality, and lower maintenance costs that arise from the kind of short cuts that a single monolith codebase makes possible.
And two code bases sounds like a reason for more shortcuts to be taken not less to me.
Testing means you catch regressions.
You seem to be talking about API design, which is honestly a minor concern compared to whether it works reliably.
Have you ever tried to use the Facebook API? It breaks randomly such as endpoints suddenly return 404's, and there is no followup to bug reports.
That is what I'm talking about when I say "quality".
A "perfectly designed" API that randomly breaks because someone made a change and the lack of tests means its an end-user who discovers it is worse than terrible IMO.
- You can throw your client app away and build a new one pretty quickly without worries because it's totally decoupled from the backend. This is really nice when you have fickle stakeholders that have no idea what they want.