Vertical Slices Beat Platform Foundations in the First Quarter

The sprint review showed authentication libraries, billing abstractions, deployment scripts, and a tenant model. No user could complete a workflow. The platform looked serious. The product had not learned anything yet.

Teams assume the responsible first move is building horizontal foundations. Auth, billing, tenancy, data access, UI kit, observability, and admin tools all begin at once. The risk is that every layer is designed against imagined usage instead of one real path.

A vertical slice is not a thin UI. It is a narrow production path. It should include front end, API, domain logic, persistence, integration, authorization, telemetry, test, deploy, and support behavior. The slice should also have explicit non-goals: tenants not included, integrations not included, roles not included, and workflows intentionally rejected or routed manually.

For vertical slices, the release review should prove one useful slice can be operated. The slice should include identity, authorization, persistent state, at least one meaningful integration when the integration is part of value, observability, rollback, and support handling for the top failure modes.

The review also needs explicit non-goals. Teams fail when adjacent workflows sneak into a narrow release through user behavior. If the release is only for one tenant, plant, clinic, region, or customer cohort, the system should reject or route out-of-scope cases intentionally. Undefined behavior is where support teams inherit product decisions.

Finally, the team should show change safety. Smoke tests, a few acceptance tests, basic telemetry, and a deploy rollback are not gold plating. They are what prevents sprint-one code from becoming year-three rebuild material.

A healthtech product team spent two quarters building intake platform components before a clinic used a single pathway. When the first workflow finally reached users, the patient identity model, audit event shape, and payer timeout handling were wrong. The team reset around a vertical slice: one care pathway, one location, one identity flow, one payer lookup, one audit trail, and one support correction path. Platform abstractions followed the evidence from that slice.

The honest tradeoff is scope excitement versus operating evidence. A broad platform plan gives stakeholders the comfort of inclusion. A narrow slice gives engineering the discomfort of real constraints. The second path is usually better because it exposes ownership, support, rollback, and integration behavior while the design is still cheap to change.

Failure tests should include authorization gaps, duplicate submissions, integration timeouts, inconsistent feature flags, tenant boundary mistakes, audit omissions, data migration rollback, and manual correction flows. If support needs database access to repair the slice, the release is not ready.

Horizontal bet:
Auth layer + billing layer + tenant layer + UI kit + data layer
                  no completed workflow

Vertical slice:
User action --> auth --> domain rule --> integration --> persistence --> audit --> support path

A useful delivery artifact should name the user path, owner, non-goals, domain boundary, data boundary, integration boundary, acceptance tests, support path, rollback behavior, and defer list. It keeps a vertical slice honest by showing what was deliberately made real and what was deliberately left out.

Horizontal work is justified when a constraint is already known and shared by many slices. Compliance logging, tenant isolation, or payment security may need early design. But even those should be proven through one path quickly. A prototype can explore UX, but production architecture should be learned through slices.

A weak review asks whether sprint scope is complete. A useful review asks whether the shipped path changes the risk profile of the business in a measurable way. The reviewer should inspect acceptance criteria for failure paths, not only success paths. If duplicate submission, integration timeout, role mismatch, or rollback behavior is unspecified, the slice is not truly ready.

Decision records matter because custom software lives longer than kickoff memory. A short architecture decision record should explain identity, tenancy, data ownership, integration style, deploy assumptions, and non-goals. The point is not ceremony. The point is giving future teams a reasoned boundary when the product inevitably changes.

The review should also compare build choices economically. A platform layer, a vertical slice, a feature flag, or a release train decision all move cost between now and later. CTO-grade delivery work makes that trade visible: what becomes cheaper next sprint, what becomes harder in year two, and what evidence will tell the team to change direction.

Leadership should watch delivery signals: slice completion with support paths, deferred scope made public, rollback exercised, integration errors observed, and owner decisions made without committee rescue. Velocity is useful only when the shipped path can survive real use.

The useful artifact is a slice contract. It should name the user path, owner, non-goals, data boundary, integration boundary, acceptance tests, support path, rollback behavior, and what must be deferred. A backlog epic is not enough because it does not say which adjacent workflows are intentionally out of scope.

This contract gives the team permission to say no. That matters more than it sounds. Most early delivery failures come from letting a narrow slice quietly become a platform bet or a quarter-end release train.

Use this decision threshold: if the slice cannot be supported without heroics, it is still a prototype no matter how complete the UI looks.

Write this note before the sprint closes: what user path became real, what platform work was deferred, what support path exists, and which evidence says the slice is not just a better demo.

A practical review should include one end-to-end slice record. Name the user action, domain owner, integrations touched, excluded workflows, support procedure, rollback behavior, and acceptance tests. This keeps the article grounded in delivery reality rather than turning vertical slices into another planning slogan.

The useful review example is one user path that can be supported after the sprint demo ends. Ask who owns the decision, what data is persisted, which integration can fail, how support corrects mistakes, and what the team intentionally deferred. That evidence keeps custom software grounded in use, not backlog completion.

A decision note should name the smallest path that teaches something under real constraints. If the path has no support story, no rollback behavior, or no owner who can defer scope, it is still a prototype wearing production language.

A vertical slice should include support and correction paths, not only the demo path. If operators cannot repair a failed transaction without database access, the slice is still a prototype. The slice contract should name what adjacent workflows were intentionally excluded so they do not become silent scope creep after the sprint review.

Platform foundations can wait; operating evidence from one real path cannot.

Slices fail when teams ship UI without the support, rollback, and integration behavior that makes the path real.

The first slice should make one workflow true. A platform that has not carried a real workflow is still a hypothesis.