Even though it depends on the context, I was wondering: during a project that requires a frontend and a backend developer, who most often starts with the tasks first? This assumes the web design is already finished and accepted - now it only needs to be implemented.

Should the frontend developer start coding the design with static data and then pass it to the backend dev to implement the backend?

I'm asking because I found this approach to be doubling the work. For example, building the frontend first with static variables, JSON, objects etc., and then passing it to the backend dev, you are never really sure how the backend dev will return the hashmap to the frontend. I've been in situations where I had to do whole day worth of additional adjustments after the backend dev finished building the API and showing to me that the frontend is a mess.

So, again, my question: who usually starts first - the frontend or the backend dev?

  • 13
    How about designing the data contracts first? May 4, 2018 at 18:30
  • 3
    When two people shake hands - who starts first? May 5, 2018 at 11:36
  • You start discussing together about your respective role and collaboration May 6, 2018 at 8:38
  • Does seem like you are suffering a lack of communication and some siloing. We resolved a lot of these problems by becoming more cross functional as a team and working together instead of this backend vs frontend
    – r_ahlskog
    May 6, 2018 at 10:10

5 Answers 5


You should do features planning. Second, your backend developer should create tasks which will be done in period of two weeks (scrum), he/she should keep every task updated and to use software like swagger to describe how implemented api looks like. Also he/she should not change already implemented apis without task and your knowing.

Then your job as frontend developer would be much easier. You will know what part of api is in development, what part is already done and you can follow swagger to know how to use api.

And also you should use real api as much as possible because that way you will detect bugs earlier :)

Edit: I think it would be great if backend team is one week or all sprint in front of you. That way you will have all things you need once you start working on it.


you are never really sure how the backend dev will return the hashmap to the frontend

Okay, that is your problem. With that problem as a given, it doesn't matter who starts work first -- it will be a gamble anyway.

I'd advise that, after "the web design is already finished and accepted", the frontend and backend developers meet and hash out the various API. They might even prepare some sample static JSONs that the frontend developer can test, while the backend developer knows that they're what he's going to have to come up with.

  • Rather than gamble you could use adapters that adjust to the differences that turn up. May 6, 2018 at 6:40
  • Adaptors are overkill for this sort thing when a conversation between devs will solve this. If the devs worked at different companies there might be a case for adaptors. May 6, 2018 at 11:59

I would first design the data contacts first then both start working on it at the same time. This may change but if designed well this should be minimal. The is the beauty of have the back end the front end in separate tiers

  • 2
    Or better IMHO work out just one contract to get full stack functionality working asap. Get one function working correctly with error handling worked out too, then build out sideways using the same pattern to complete the rest of the functionality
    – Bohemian
    May 4, 2018 at 20:27
  • @Bohemian that is super true but the key that neither need to be completed first just work with a working contract and build what you want to build
    – Joe Tyman
    May 4, 2018 at 20:31
  • 1
    I think neither should be completed first - it's best if both sides work at the same time to evolve the functionality and API together
    – Bohemian
    May 4, 2018 at 20:48

Both should start working first, for example if the frontend developer has to show the status of a message, both should work together and came out with an api, for example /api/v1/status/333 (GET),the result is an JSON, etc.


You should do both concurrently, with collaboration. This can largely depend on technology at play. I assume by front-end developer you mean either Xaml or Html/Css depending on the application, and by backend, web services, business logic, and data access logic.

You should have collaborated enough already that both know what the objective is. Your front-end developer can build the entire user interface working with hard-coded JSON DTO objects, while the backend developer can iron out all the data access, business logic, and web services. The DTO and web services can be tweaked, since these are the glue in between. You do need to be "close" on what the DTO might look like, but it does not have to be exact, but you should have collaborated before doing either "end" of the project, so there isn't this large adjustment when you need to integrate the layers together. This includes deciding up front what potential service calls and data transfer objects might be at play, and as each developer runs into potential design problems or issues, they should be collaborating with one another to alter the design at that point, and not at the end.

It sounds like you have a process/communication problem.

Usually you do need to complete the backend first so the front-end developer can replace the hard coded DTO objects with actual service calls, and there needs to be some collaboration here, especially integration testing before these bits are sent off to a tester.

We have developed several projects successfully this way, and when done right, you can get faster concurrent development, rather than linear development. Our reason for moving to this approach is we are a scrum team, but have skillset gaps and different strengths, so we are utilizing the layered architecture appropriately to allow people to work in their strength areas, and develop features concurrently.

Caveat - not all features or projects lend itself to this methodology, but if you can do it, I would highly recommend it.