Open any frontend (FE) ticket, and you’re likely to find a whole variety of visual requirements, files, & documentation. Anything from the user journey flows, to mockups, designs, and fully-baked UI components — all are there to make sure you, as a frontend developer, get everything you need to get going & to do things correctly.

I am not criticising — quite the opposite. Frankly — I’m jealous 🤩

Most engineers would agree that the backend (BE) logic is not less crucial or complicated than frontend logic. If anything, some of the most business critical decisions and calculations take place on the backend.

Take financial calculations of a price 💸, for example. Or interest rates, fulfilment processes in an e-commerce product, or even live ML training based on production datasets 🧠. All of these aspects affect not only the profitability of the business, but also its risk tolerance, cyber security and legal compliance.

So how come the best a backend engineer can hope for, is just a dry textual ticket? Or, if they’re extremely lucky, a link to the relevant frontend journey? (Which would be over at this point, so would only act as documentation for the ‘entry point’ of the backend flow?)

I think it’s branding 🤷‍♂️

For some reason, backend development is seen by many as a realm of dark magic, a bear that should not be poked without reason. Or, putting jokes aside, it is seen as something that has nothing to do with the user journey and experience, even though it has everything to do with the user journey and the user’s experience.

But that doesn’t matter, we are here to change that, not to complain about the past. Here is what we can do to bring the backend realm into the 21st century 🤘

1. Plan end-to-end journeys, including the BE logic and permutations.
Let’s look at a fintech example — here is how a simple KYC (know-your-customer) process would look like in an end-to-end journey;

As you can see, it provides context to everyone. Frontend, backend, QA, Product Managers, everyone. Whoever looks at it — will understand what they need to do, and how their individual work connects to the individual work of other people in the team 🤝

2. Compile a story readiness checklist which includes the most important aspects, here’s an example:

• Happy flow is clear and concise
• Failure of every step is considered in terms of API response, and a corresponding message on the FE is defined
• Timeouts and unresponsiveness of the server are all taken care of in terms of messaging for the user
• Monitoring errors is as solid on the BE as it is on the FE, including the steps which lead to the issue, as well as the stacktraces and source mappings
• Requirements for analytics events are outlined & well-documented, preferably in the same place as the user journey
• Test strategy is defined, with edge cases clearly identified both for FE and BE
• Release time is scheduled
• Rollback strategies are defined & documented
• What has to be feature-flagged — is feature-flagged, both on the FE and the BE

3. Make sure you’ve got a way to ensure that the BE works as expected. While it is easy to achieve this on the frontend (i.e a certain page leads to a different page, or the right message is displayed to the user, etc.) — it’s not at all trivial to achieve that in the backend 🤔.

This is where tools like STATEWIZE would come into play, and assist with ensuring that the plan matches the reality, both on the FE and on the BE.

And this way, finally, backend developers will get what they, nay we, truly need in order to do our job in the most efficient, correct & seamless way possible.