Why Horizontal Slicing is Killing Your Product Delivery

Our Case Studies

I keep seeing the same pattern in organisations big and small: splitting front-end and back-end work into separate streams or teams. I’ve come across it while helping companies in Australia, Europe, and the US, and it always leads to the same issues — slower time to market, harder automated testing, and no room for a true build–measure–learn cycle. In this post, I’ll explain why this approach fails and share a far better way to work.

This split between front-end and back-end is an example of horizontal slicing — dividing work by technical layers. The problem is you don’t get any working software until all the layers are complete and integrated. From a product perspective, this delays feedback from real users. From a technical perspective, it increases the risk of late-stage integration issues and makes testing far more complex.

Horizontal slicing creates problems on both the product and technical side. From a product perspective, it takes longer to validate ideas, delays ROI, and makes it harder to learn and find product–market fit. You have to build far more before you can get any meaningful feedback. From a technical perspective, it complicates end-to-end testing, slows down CI/CD, and forces teams into constant context switching while waiting for other pieces to be ready or fixed.

From a technical perspective, horizontal slicing creates a long list of avoidable headaches. End-to-end tests become harder to write and maintain because the system is never in a working state until late in the process. CI/CD pipelines slow down as features can’t be deployed independently. Developers spend more time waiting for APIs or UI components to be ready, leading to constant context switching. Code merges take longer and are more painful because large, incomplete branches sit open for weeks or months — often diverging so far that merging becomes a mini-project in itself. Integration usually happens at the end, which is when the most expensive bugs appear, forcing rework across multiple teams and codebases.

I’ve seen this play out with teams where a “simple” feature took months to ship. The front-end team built the UI and waited weeks for the back-end to finish the APIs. Meanwhile, the back-end team completed their part but couldn’t validate it without the UI. Both sides accumulated large branches that became harder to merge by the day. When everything finally came together, integration bugs appeared, automated tests failed, and release dates slipped — all before a single customer saw any value.

A better approach is vertical slicing — delivering features end-to-end, from the UI down to the database, in small, releasable increments. Each slice is a piece of working software that can be tested, deployed, and used by customers. This allows teams to validate assumptions early, measure impact, and make informed changes before investing heavily. It also keeps code changes smaller, merges simpler, and testing faster because everything needed for the feature is built and integrated in one go.

As a product manager, you can keep user stories or intended outcomes small enough to be released independently. This makes it easier to gather feedback through multivariant testing or usability sessions without waiting for a larger release. Technically, this approach is stronger too — end-to-end tests can run on complete features, production stays ahead of development, and teams can push to production multiple times a day with confidence.

So why do companies keep doing this? A big reason is specialisation — people prefer to work on what they know best. Some developers avoid the front end, others steer clear of the back end. The result is parts of the codebase that depend entirely on specific individuals. And when those individuals are unavailable — say Jack is on holiday in August — that payment integration, or any other critical feature, sits untouched.

There are two practical ways to break the specialisation trap. First, get your front-end and back-end developers to pair regularly, focusing on strengthening their weaker areas. This will only work if user stories are written as vertical slices, which may require significant changes to how your product managers operate alongside the technical uplift. Second, bring in a partner like Impekable to lead by example and help with capability uplift — showing teams how to deliver vertically sliced, end-to-end features while embedding those practices into their daily work. Add TDD and CI/CD to this mix, and you’ll see a huge improvement in speed, quality, and team confidence.

If you’re still splitting teams along front-end and back-end lines, it’s time to stop. Horizontal slicing slows you down, hides risks until it’s too late, and keeps your product further from your users for longer. Restructure around vertical slices, invest in cross-skill pairing, and bake in TDD and CI/CD. Your teams will deliver faster, your quality will improve, and you’ll learn from your users sooner — which is the only way to stay competitive.

Pek Pongpaet

Helping enterprises and startups achieve their goals through product strategy, world-class user experience design, software engineering and app development.

Let’s Talk

|