The line between frontend and backend isn’t a technical boundary. It’s a social one. It’s a reflection of what people feel comfortable with, echoed in software. And once it’s on the Jira board, it starts shaping how the feature gets built: two people, two contexts, one interface neither of them fully owns. 

This post is about why that split is worth resisting, and how thinking about it differently leads to better software. 

How it usually goes down 

We’re on our regular sprint planning, we realize what needs to be done for the next sprint, so we move existing tasks into the sprint and create new ones as needed; all the usual practices. But time and again I see the same things happening, separate frontend and backend tasks prefixed with “[FE]” and “[BE]” respectively. This has become a real tradition in our planning process; we do it because we’ve always done it. Someone sees an opportunity to split another task, so they do it, almost instinctively, and nobody asks questions, because the split is already so ingrained into the process. 

I see a lot of developers think like this. They see this large boundary, so large it makes them think the only way forward is splitting the task by that boundary. And as a bonus it scratches our “breaking down a big task into smaller ones” itch, which is always a good call. Well except here. This boundary is entirely artificial. 

Real reasons behind the boundaries 

We keep making up this artificial boundary in our systems, because it is actually real, except it lies in another area, people’s familiarity and preference for either frontend or backend. 

Engineers who are equally comfortable on both sides are uncommon. Most prefer one side of the stack, so we tend to make separate tasks so everyone can work on whatever they are most familiar with. It’s only natural to want to avoid the psychological barrier of dealing with something you’re not 100% accustomed to. It’s also normal to strive to reduce your company’s development time and thus cost by doing something you’re fast and good at. 

Organizing around people’s comfort zones is fine. Letting it reshape your architecture is where things go wrong. 

How the split leads to tech debt 

Transferring this boundary from people into our systems creates a variety of problems. For example, as one person gets a task to create an internal API endpoint for retrieving some data and another person must consume this endpoint on the frontend, whatever kind of endpoint was created, it’ll be called by the frontend. “This API was provided to me, so I’m using it” the dev thinks – except it wasn’t provided, we ourselves created it. Effectively the important process of iterating on an idea or feature disappears. 

Generally speaking, the whole feature implementation has a high likelihood of being sloppy, buggy, non-performant and starts right off as tech debt. 

A call is a call 

At Infobip, with our microservice architecture, we have similar “fake” boundaries between each service. In fact, these boundaries are identical, apart from the protocol used – HTTP or remote procedure calls (RPC). 

The fact that the call passes over the network, instead of being a plain Java, Kotlin, C#, Python, etc. call, shouldn’t mean anything to us*. When it comes to backend work, we don’t see these boundaries, and by equating them with the frontend-backend boundary we get to the realization that the frontend-backend split is indeed artificial. 

*Of course, sometimes we need to add caching or bulk methods, but that’s beside the point. 

My advice would be to strongly avoid splitting feature tasks by layer. A single person should own a feature end-to-end, from the database to the UI, because only then can they see the full picture, catch problems in the approach early, and build a coherent mental model of how everything fits together. As John Whiles writes in Suddenly, I Understand Software, that kind of deep, complete understanding is what separates someone who implemented a feature from someone who truly gets it. 

Conclusion

The frontend-backend split feels obvious, but it’s a trap that leads straight to tech debt when we let it shape our development process. It’s a social boundary, not a technical one, so we should bridge it and let people develop a full understanding of a feature before iterating on it.