FIELD NOTES·PROCESS·7 MIN READ

{{ shareLabel }} Print {{ saveLabel }}

Most software projects are built the wrong way around. Teams spend weeks on the database schema before a single user sees a screen. APIs are wired up before anyone confirms what data is actually needed. The UI gets bolted on last — and by then, the assumptions buried in the data model are too expensive to revisit.

This is horizontal development: build the entire persistence layer, then the entire API layer, then the entire frontend. It feels organized. It has a certain engineering tidiness to it. It is also, in practice, the most reliable way to ship the wrong thing — because by the time any user touches the software, you've already made hundreds of decisions that can't easily be unmade.

The alternative is a vertical slice: one small but complete feature, all the way through the stack. Not a mockup, not a prototype — working code that touches the database, passes through the API, and renders in the browser. Everything else waits.

What a slice actually is

Jeff Patton calls this a walking skeleton. The skeleton is the minimum structural piece that can be deployed and demonstrated — it proves the system holds together end to end. Once you have a skeleton, adding features is additive rather than transformative. You're not refactoring the foundation every time you add a room; you're furnishing a house that already stands.

The "thin" part matters as much as the "vertical" part. The slice should be the narrowest piece of real user value you can identify — not a hello world, and not a whole feature set. One complete flow, usable by an actual person, that returns something meaningful. A user can create a record. A field tech can submit a report. A broker can see their pipeline. One thing, fully working.

The slice is not a demo. Demos exist to impress. Slices exist to test. The distinction matters when it comes time to decide what to build first.

How to choose the right slice

The right thin slice is not the easiest thing to build. It is the thing that tests your riskiest assumption. Every project rests on a set of assumptions — about what users will do, about what the technology can do, about whether the value exchange makes sense. Most of those assumptions are probably fine. The dangerous ones are the ones that, if wrong, invalidate the whole project.

Technical risk. If the core of your idea depends on a specific API integration, a particular data transformation, or a latency budget that might not be achievable — that's your slice. Build the thing most likely to kill the project first. If it doesn't work, you want to know in week one, not week twelve.

User behavior risk. If you're building something that requires users to change how they work — upload files instead of emailing attachments, check a dashboard instead of asking their manager, enter data in real time instead of at the end of the day — test that behavior assumption with working software before you build twenty features around it.

Business model risk. In commerce and SaaS projects, the payment flow is often the right first slice — not the feature. Nothing reveals whether you've built something people genuinely want like asking them to pay for it.

What weekly demos actually change

At Blufrost, we ship a working demo every week — not a slide deck, not a Figma prototype, but deployed software you can click. This is not a client-management habit. It is a forcing function that changes how everyone on both sides of the project thinks.

When clients see working software every week, they stop asking for hypothetical features and start reacting to what's in front of them. The conversation shifts from "I want a feature that…" to "this screen does X — can it also do Y?" That's a much more productive conversation, because it's grounded in something real.

"The weekly demo also makes scope negotiation honest. When a new request comes in at week four, you look at the demo together and ask: is this more important than what we planned for week five?"

That conversation, grounded in working software rather than abstract plans, almost always produces better decisions. Engineers stop gold-plating code that hasn't been validated. The feedback loop compresses from months to days. Everyone can see exactly where the project is — not on a Gantt chart, but in the product itself.

The thing teams resist

The thing most teams resist about slicing is the feeling of incompleteness. A thin slice looks, from the outside, like an unfinished product. The database has one table. The UI has one screen. The feature doesn't handle edge cases. It's not ready for production, and it probably doesn't look impressive.

That discomfort is the point. Shipping early means being wrong early — and being wrong cheaply. A wrong assumption discovered in week two costs a few days to fix. The same assumption discovered in week ten costs a partial rewrite, and the momentum loss that comes with it.

The teams that wait until everything is connected before showing it to anyone are not being thorough. They're deferring risk until it's too expensive to address. Ship the slice. Find out if it holds. Build from confirmed ground.