At that point we start individually writing documentation for our respective pieces, (as if those services already existed). This might take the form of Readme files, wikis, or formal API documentation.
Normally the process of writing documentation (and getting feedback on it) flushes out of a lot of issues. When everything is documented and everyone is on the same page about what everybody else is doing, then we write our tests and repeat the same feedback process. Once everyone's tests are on the same page, then we write our code, and do a code-review when that is done.
Even with all those checks and balances, mistakes and confusions and miscommunications still happen. But having those regular check-ins to flush out issues before the real code gets written can save a lot of headache. If you get to the code review and find an issue, it's probably not going to be a huge one.
Prototyping the user interface can be done by any number of people any number of times, since the goal is to experiment with different ideas. The backend APIs are usually mandated by what the user interface requires.
You find what things might stop your project going live and work on those things first. If they can be worked on in parallel even better.