How thin vertical slices drive adaptive software delivery
The most valuable thing a stakeholder can tell you about your software is “that can’t possibly work.”
It sounds like a failure, but it’s actually one of the strongest signals you’re making progress. If a stakeholder immediately agrees with everything you’ve built, you’ve probably confirmed assumptions they already had. But when a small piece of working software makes them stop and stay, “Wait… that won’t work,” you’ve uncovered something much more valuable than whether the feature functions. You’ve exposed an assumption, a hidden requirement, or an opportunity to solve a better problem.
That’s the real purpose of a thin vertical slice: it teaches you something you couldn’t have learned any other way. Every slice should answer a question, and the answer should shape what you build next.
Learning faster by building less
On a federal claims processing modernization effort, our team faced a high-priority, cross-team request. Stakeholders needed visibility into claims processing across multiple systems, comparing what our new system produced against the legacy systems still running in production. The data they wanted was scattered across those systems, neither centralized nor accessible. Initially, the work looked like a two-week story involving a user interface, multiple system integrations, and various metrics. Instead, we asked a different question: What’s the smallest thing we can build that tells us whether this information is actually valuable?.
The answer was surprisingly small. The first slice involved two APIs, one metric, and a REST endpoint returning JSON. We displayed the metric on a static web page. At this point, there was no need for authentication, complex user interfaces, or polished reporting. The single question we needed to answer was: is this data point even valuable to the stakeholders? We shipped it to production in 2 days, got the answer we were looking for: Yes, this information is valuable. Build the next thing.
Subsequent slices added external system integration, more data elements, and eventually an HTML page served by Spring Boot, built quickly with help from Claude. Every slice was security reviewed, had full test coverage, and was deployed to production. Every step of the way, the feedback drove the next priority.
What is a vertical slice?
A vertical slice is a small, complete piece of deployable, testable software that solves one specific user problem from beginning to end. It exposes integration, architecture, and political risks early, delivers value before the full system is complete, and lets real feedback guide what comes next instead of outdated plans.
A slice is not a mockup or a partial implementation. It is a working piece of the system that people can use and respond to.
Most importantly, a vertical slice is designed to answer a question. Sometimes the question is whether users find something valuable. Sometimes it’s whether two systems integrate correctly. Sometimes it’s whether an architectural approach will scale.
Why a deliberately simple slice unlocked a modernization
On another federal modernization effort, the client asked us to migrate appointment status codes from an aging SQL Server database into the new system. The status codes had evolved over years. Codes meant different things in different contexts, and no one could fully explain why they worked the way they did.
Rather than faithfully migrating that mess in a single slice, the team built something deliberately simpler: active and inactive statuses for a single context. When we demonstrated it, the client said, “That can’t possibly work.” This reaction opened exactly the conversation that mattered. As we talked through why it “couldn’t work”, something became clear. The client didn’t actually like the legacy status model, but they had assumed they needed to preserve it. That narrow slice freed them from a mental model of “we have always done it this way,” and it surfaced additional, higher-value work in their core mission that they had not known could be delivered quickly.
Instead of spending months recreating unnecessary complexity, the conversation shifted toward what the new system should accomplish rather than what the old system happened to do. The vertical slice helped the client imagine a better future. Our work on the hidden waste in government IT digs further into how inflexible legacy systems trap organizations in expensive habits.
The hardest problems are usually people problems
One of the most overlooked benefits of vertical slices is that they expose organizational friction early. When a slice spans different groups and functions, it tests governance, approvals, security reviews, ownership boundaries, stakeholder alignment, and operational processes. Those are often the factors that determine whether an effort succeeds. By discovering those constraints while the slice is still small, teams can adapt before they become expensive schedule problems.
How to vertically slice effectively
- Slice for the next thing you need to learn, not for the largest chunk you can build. Boil everything else away and ask what question the slice will answer.
- Demo every slice to real stakeholders, fast. Working software shown in days surfaces feedback that a roadmap document never will.
- Treat “we don’t need this after all” as a successful outcome. Our instinct is to add. Sometimes the right move is to take a feature out or defer it entirely.
- Expect the hard problems to be social, not technical. A slice that crosses team and agency boundaries forces political and cultural unknowns to the surface early.
- Watch for evidence of impact, not just completion. Ask whether the thing you shipped actually mattered to anyone before building the next layer on top of it.
The payoff is that each slice delivers value on its own. Stakeholders see working software sooner, begin getting benefit from parts of the system before the whole is finished, and realize return on investment earlier. This is the same dynamic we have written about in how feedback loops build better software, faster, applied to the question of what to build next.
Build vertical slices to learn
- Pick the smallest slice that answers your single most pressing unknown. Resist bundling extra scope into it.
- Ship it to production and demo it to real stakeholders within days, not sprints.
- After each slice, ask two questions: What do we need to learn next? Did what we just built actually matter?
- Periodically challenge what has accumulated. Be willing to remove or defer features, not just add them.
The slice, ship, learn, re-plan rhythm is what adaptive delivery looks like in practice. It’s about letting evidence change your direction. That’s why hearing “that can’t possibly work” is a gift. It is feedback you could only have earned by putting something real in front of someone. The slice that provokes a reaction has already done its job, because it has told you where to go next.
If your team is wrestling with how to sequence a complex build or modernize a system that people are reluctant to let go of, our approach to adaptive software delivery is built around exactly that kind of learning, one slice at a time.
Published on Jul 01 2026