It doesn’t matter if you’re building a mobile, desktop, or a web app – nowadays pretty much everyone breaks their applications into a frontend that uses the latest, hottest javascript framework and a backend responsible for answering ajax requests.

Arguments on what should go first, the frontend or the backend, are always there.

In my experience, doing either one first will only lead to conflicts and feelings of resentment between the two camps. Front devs will be annoyed because “the APIs are always changing” and the backend guys will be like “why can’t you understand that we had to change x thing?”.

In the software industry, everything is a subject of change. Trying to agree on the API structure and creating dummy JSON files to substitute for the real thing while the backend devs figure out their stuff isn’t a solution.

Even more so, agreeing on such a contract will harm the project in the long term. Each part will try (and fail) to hold on to their part of the deal rather than reaching out to the best solution and approach for the problem at hand.

Next time, keep the team as small as possible (2-3 people), break the application into medium sized components, and start working “as one”. Agreeing on a pre-defined structure never worked in my case. We made great progress when we focused on the same component at once – with the front dev leading the way.