Thin Vertical Slices: Full-Stack Pragmatism
Why one feature shipped end-to-end beats six features built horizontally, and how Palantir's 'Delta' model formalizes the idea.
Horizontal teams ship horizontal nothing
When engineering work is organized by layer (a backend team, a frontend team, an ML team), the natural unit of progress is 'we finished our part of the layer.' This works at scale, with a planned roadmap and a stable definition of the product. None of those conditions hold in FDE work. The customer hasn't committed yet, the requirements will change in two weeks, and the only feedback loop that matters is putting something usable in front of them. In that environment, horizontal progress is invisible. There is nothing to show until every layer finishes. Palantir's 'Dev vs Delta' framing exists precisely to separate the two modes: Devs work the platform horizontally and ship one capability to many customers; Deltas (FDEs) work the customer vertically and ship many capabilities to one customer. Mixing the two roles in one engineer produces someone pulled in two directions and shipping neither well.
What 'vertical' means in practice
A vertical slice is one user-facing capability implemented through every layer of the stack, even when each layer is the minimum viable version of itself. For an FDE proof-of-concept, that often means: a hardcoded auth user, a single API endpoint, a query that hits the customer's actual database (or a static export of it), a small inference call to whichever model is appropriate, and a UI that has one page and two buttons. The point isn't that any of these layers is good; the point is that the feature exists in the customer's hands and can be evaluated as a feature. A backend with sixteen endpoints and no UI cannot be evaluated as a feature; it is a promise. Anthropic's posted FDE role lists 'MCP servers, sub-agents, agent skills' as the kinds of artifacts the engineer ships. Each of those is, by design, a slice that runs end-to-end.
The 'ugly but real' standard
Slices done well are ugly. The UI uses default Tailwind, the API has no validation, the prompt is a string concatenation, the data is loaded synchronously. None of this is what you'd ship to production. All of it is what you ship to a customer in week one. The instinct to make it 'just a little nicer' before showing it is the most expensive instinct in FDE work. Every hour spent on polish before validation is an hour spent on something that might be deleted on Tuesday when the customer says 'actually we don't care about this part, we care about that other thing.' Polish only what has been validated as the right slice.
When to widen the slice
After the first slice lands and the customer confirms it solves real pain, you have a choice: deepen this slice (more polish, more edge cases, real auth, persistence) or add an adjacent slice. The right call is almost always 'add the adjacent slice first.' Two ugly slices side by side are more revealing than one polished slice; they expose whether the customer's enthusiasm extends across their workflow or was specific to that one thing. Only after three or four slices are running, all roughly to the same standard, should you start the polish work. By then, the customer has implicitly told you which slices to invest in by which ones they use and which ones they ignore.
The state-management trap
The largest accidental yak-shave in FDE work is state management. Engineers reach for Redux, or a database, or a job queue, the moment the prototype has more than one screen, because their training tells them to. Resist. A POC almost never needs server-side state that survives a refresh. It almost never needs a job queue; synchronous calls are fine until they aren't, and 'until they aren't' is rare in a demo. It almost never needs proper auth; a hardcoded user is fine. Every infrastructure decision you defer is a decision you don't have to defend or maintain. The customer does not see the absence of Redux; they see whether the feature works.
Key takeaways
- •Horizontal progress is invisible to a customer. Vertical progress is the only kind that moves the contract.
- •Palantir's Dev vs Delta split formalizes this: one capability to many customers (horizontal) vs many capabilities to one customer (vertical).
- •A vertical slice goes through every layer at its minimum viable version, top to bottom. Anthropic's MCP servers, sub-agents, and agent skills are framed as slices for the same reason.
- •Ugly is correct. Polish before validation is the most expensive instinct in FDE work.
- •After the first slice lands, add a second slice before deepening the first. Adjacent slices reveal real preferences.
- •Defer all infrastructure (state stores, queues, auth, deploy) until the customer's behavior tells you which slice to invest in.
Exercise
Take an internal tool at your company that you've used. Identify the single workflow that matters most. Describe what a one-day vertical slice of that tool would have looked like, naming what every layer would do at its ugliest. Compare that to how the tool was actually built. Where did horizontal investment cost you weeks?
Self-check
- 1.Why is a backend with sixteen endpoints and no UI worse than a backend with one endpoint and a UI for FDE work?
- 2.Why is the second slice more informative than polishing the first?
- 3.How does Palantir's Dev vs Delta distinction map onto 'horizontal vs vertical' progress?
- 4.Name three infrastructure decisions a POC almost certainly does not need.
Sources