Ever started a new project and wondered: “Where do I even begin?”
That was where I was at, in and during my Jammming project on my GitHub. I knew what I wanted to build but once I got into the code, it all started to unravel. I jumped between components. Refactored things I hadn’t even finished. Tried to connect backend endpoints before the frontend was working. It became chaotic, and became slow. Bugs were hard to track. I didn't know where to begin. In the build phase it was all a bit chaotic. In fairness to myself, I was figuring out react, but it got me thinking about how I'd approach the process in the future.
With my background in startups / being a product manager I'm familiar (like you probably are) with agile methodology, the learn Build-Measure-Learn cycle. In particular I was used to thinking about an MVP in desiging products.
But when it came to building, MVP thinking didn’t help. It told me to build a "skateboard before the car"—but how does that translate to actual code how we tackle a project? If you're not super geared up with design patterns and architecture it's quite difficult to usefully break down an MVP.
If you're in product you're probably familiar with the challenge of measuring meaningful progress without bugging your engineers. With my engineer hat on, the limits of MVPs are clear.
To overcome the where can I start problem, In this post, I’ll share the idea of the Minimum Viable Slice—a small, deployable, technically complete unit of functionality that helped me break through that builder’s block and start making confident progress.
The Problem with MVP Thinking
We’ve all heard it: start with the simplest version of your product. And yes, Minimum Viable Product (MVP) thinking is great from a business and user perspective. But when you're the one writing the code, “simplest product” doesn’t always give you a clear place to start.
In practice, it left me floundering. What should I code first? Should I build the UI? The database? Some mocked-up flow?
What ended up happening was:
- I jumped between frontend and backend
- I introduced bugs by half-implementing features
- I rewrote logic as the scope shifted
- I found it hard to test anything in isolation
The result was a messy codebase, lots of rewrites, and slow progress.
What Is a Minimum Viable Slice?
A Minimum Viable Slice (MVS) is my antidote to MVP ambiguity. It’s a narrow, technical-first way to scope and build your project incrementally.
Here’s how I define a slice:
- Mergeable – a slice can be safely merged into main without breaking the system
- Testable – its core function can be verified (input → output) through tests or basic interaction
- Functional – it delivers a clear technical goal (e.g. auth, persistence, or an API integration)
A slice can be designed to be mergeable to main, deployable to a staging environment, or even production-ready—depending on your goal. The point is that it’s internally stable and complete, even if it’s not yet user-facing. Ultimately, I think of MVS as more of a guiding principle than a rigid set of rules.
It’s not style-focused.
It does not need to be user-facing.
It’s not concerned with polish.
The focus is just something that's technically functional and deployable,
Each slice stands on its own and pushes your architecture and build forward.
How MVS Helped Me Scope My LLM App
After the Jammming experience, I wanted to address some of the builders block / pitfalls in my next project - a full-stack LLM app.
Whereas in Jammming I did a sketch and went all out, I decided to create a hybrid scope / technical design document.
In the technical scope defined my requirements, problem etc and then I broke the app down into slices. It's still a work in progress and this post is reflecting on my learnings / things and research but at time of writing, at a high level it looked like this:
- Basic LLM Prompt Loop (No Auth) - Set up a functional prompt → response loop using the OpenAI API, in a Dockerized full-stack app.
- User Authentication - Introduce user authentication to enable personalised features and secure user-specific routes in later phases.
- Prompt History & Persistence - Add database-backed storage of user prompts and LLM responses, enabling a personal history view for logged-in users.
- Milestone Guidance via System Prompting - Use system prompts to generate simple milestone guidance based on prior user input, without external knowledge grounding.
Each slice was designed to be technically complete enough to be merged and tested as part of the main project. For example, I could implement and validate the LLM prompt loop without needing auth or persistence yet. The slices aren't standalone services—they’re functional steps that fit together into a cohesive build.
This way, I could:
- Make real progress (each slice was visible and testable)
- Focus on technical design early
- Avoid rewrites by building modularly
- Keep motivation high (tiny wins add up!)
I’ll try to share a snapshot of my slice plan once I publish the repo.
MVS vs Vertical Slice Architecture vs MVP
You might be thinking: isn't this just vertical slice architecture?
Sort of — but with a twist.
| Concept | Focus | Typical Use |
| Vertical Slice Architecture | Feature-oriented: full stack per feature | Layered monoliths, clean architecture |
| Thin Slice MVP | User-facing smallest product value | Agile product teams |
| Minimum Viable Slice | Technical scope, user-facing optional | Solo devs, junior engineers, breaking your build down |
Common Pitfalls to Avoid
- Tightly Coupled Slices: If one slice breaks when another changes, it defeats the point of isolating functionality.
- Vague Interfaces: Without clear input/output definitions, later slices may cause conflicts or rewrites.
- Backend Bias: It’s tempting to over-focus on infrastructure. Include minimal UI views early to maintain usability context.
- Skipping Tests: Tests give you confidence that each slice is safe to merge. Even basic checks help.
- Endless Refactoring: Log ideas for improvements, but move forward slice by slice. Avoid reworking every layer with each new addition.
MVS is about building up the infrastructure and logic before focusing on polished, user-facing experiences.
It gives you a structure to think and build incrementally—even when you're working solo or figuring things out as you go.
When to Use It and How to Start
I’ve found MVS especially helpful in these scenarios:
- Building side projects or learning apps
- Rapid prototyping (e.g. hackathons)
- Scoping complex systems without overwhelm
- Feeling builders block at the start of a project
Here’s how I recommend getting started:
- Define the core purpose of your project
- Write down the technical concerns or building blocks
- Break those into “slices” that can be isolated and deployed - try and design slices so that minimal refactoring is required for subsequent slices.
- Order them logically—start with what other pieces depend on - this informs your architecture and details.
- Deploy and test each slice before moving on
This shifts your thinking from “what features do I need?” to “what system pieces do I need to see working?” Another way of thinking about it is you are building internal features / system features.
Lessons Learned and What’s Next
Since using this approach, I’ve felt more clarity and less frustration in starting a project / planning.
This has also got me thinking more about interface design, and the gaps in my knowledge there. I might do a deep dive onto interface design later / share my learnings.
I’m currently using this method to guide my LLM web app build—and I’ll be publishing the full project, plan soon.
I'll test this approach, so if I find issues with this approach I'll try write about it and share my learnings... stay tuned for updates!
Summary
A Minimum Viable Slice doesn’t replace MVP or vertical slice architecture— it complements them. It gives you a practical way to start building things without getting overwhelmed.
It’s deployable, testable, and keeps your project moving.
It gives you a way to break things up logically.
Have you tried scoping your projects like this?
Connect with me on LinkedIn or check out my GitHub. I’d love to hear how you approach scoping and breaking down projects and thinking about architecture and design.
What’s Next?
I’ll use this blog to share what I’m learning, document side projects, reflect on my journey into software engineering and to share my thoughts on the industry.
You can sign up for email updates here or follow my GitHub as I build stuff 🙂
