Vertical Slice vs Prototype vs MVP: What to Build Before You Pitch Publishers or Investors

They answer three different questions. A prototype asks whether the core idea is fun. A vertical slice asks whether your team can build the game to one finished standard. An MVP asks whether real players will use the game and come back to it.

What is a vertical slice in game development?

A vertical slice is a small, fully playable part of the game built to final quality, so people can see what the finished game would look, sound, and play like. It’s called vertical because it cuts through every layer at once: design, code, art, animation, audio, effects, and UI, for one level, mission, or gameplay loop. A horizontal approach would build one layer across the whole game instead, such as the code for every level, with no final art.

A slice is one stretch of play that a person can start and finish in a short sitting. If the budget can’t cover final-quality art, a smaller slice is better than a stretched one.

What is an MVP in game development?

An MVP in game development is the smallest version of a game that real players can play and that teaches you something about them. The idea comes from software startups, where Eric Ries, author of The Lean Startup, defines a minimum viable product as the version that lets a team learn the most about its customers with the least effort.

For a game, that means a working core loop, a tutorial, saving, a build players can install, and analytics so you can see where people quit. It’s most common on mobile, where studios often soft launch in a few small markets and watch retention before spending on marketing. It suits premium story games less well, because those lean on a strong first impression.

What counts as a game prototype?

A prototype is a rough, playable test of the riskiest idea in the game, built quickly with placeholder art. It answers one question, such as whether a grapple feels good or whether a puzzle mechanic stays interesting past the first level. Many teams make several small, throwaway prototypes rather than one big build.

Vertical slice vs prototype

A prototype can look ugly and still do its job. A slice can’t: its features and systems have to work together with final-quality assets, which is also why it takes longer to build. You’re no longer testing one mechanic, you’re showing that art, code, audio, and UI hold together.

Vertical slice vs MVP

A slice is short and curated, so you control what the viewer sees, often with you sitting next to them. An MVP has to survive strangers: a tutorial that makes sense without you, saves that work, and a build that doesn’t fall over on a phone you’ve never tested. A slice can’t tell you whether players come back after day one, and an MVP can’t show a publisher how good the finished game will look.

Game prototype vs MVP

A prototype tests whether something is fun, which a few people on your team can answer. An MVP tests whether someone who isn’t your friend plays it twice, which needs a store-ready build and a way to measure what they do. You can throw a prototype away without anyone noticing. An MVP has players, reviews, and sometimes revenue, so it’s harder to walk back from.

Publishers want to play something before they sign. For a publisher, a vertical slice is usually the strongest thing you can send, though what counts as enough varies from one publisher to the next.

A typical pitch pack, such as the one tinyBuild asks for, is an easy-to-play build with a vertical slice of gameplay, a short GIF, a trailer or gameplay link, a few bullet points, and a note on any funding you need. Past releases help too, because they show you can finish a project.

A slice is meant to be final quality, but publishers know a pitch build won’t have every asset finished, so some placeholders are fine. Polish the part that carries your hook, and leave the secondary screens and levels rough.

Some publishers will talk to you at the prototype stage, before you’ve built a slice. Rami Ismail, co-founder of Vlambeer, argues that a publisher’s interest in the idea changes little between prototype and slice and that what changes is their belief that you can make it.

Submission rules differ, and some publishers want a form, a link, or a video before they ask for a build. Read each publisher’s page before you decide what to build.

Sometimes. A playable prototype can change how an investor sees your game, as long as it’s fun right away and you’re clear about what the money will build. Investors often hold back at the very start, though, unless the founders already have a track record or a high profile.

Beyond the build, investors will want the business basics: burn rate, staffing plan, porting costs, post-launch plan, and marketing. What they need from the build itself depends on what they’re worried about. An investor worried about production risk wants proof the team can build the finished game, which points to a vertical slice. An investor worried about demand wants player behavior, which points to an MVP with real retention numbers.

If you don’t know which one you’re talking to, ask what they’d want to see before you build anything.

What does each audience judge?

If you have nothing playable yet, build a prototype. If the prototype is fun and you’re pitching a publisher, build a vertical slice. If you’re pitching an investor and the game is mobile or free-to-play, an MVP with real player data may carry more weight.

Build the part your audience will judge, and keep the rest rough on purpose. Each of the three needs different things.

For a prototype, untextured blocks for levels, placeholder art, hard-coded values, and debug menus are all fine. Skip saving, settings, and menus. Aim each prototype at one question, so you know what the result means.

For a vertical slice, build one stretch of play from start to finish with final art, animation, audio, effects, and UI, plus the systems the player touches, such as combat, movement, or progression, working together. Run it on the hardware you’re targeting, since frame rate problems and loading hitches show up there and not on your development machine. Some things can be scripted or hand-held, like a fixed enemy spawn or a locked camera, as long as you say so in the pitch.

For an MVP, you need a working core loop, a tutorial that makes sense without you, saving, crash reporting, and analytics events so you can see where players quit. Decide what you’ll measure before you ship, because you can’t recover data you never logged.

One decision to make early is which code you’ll keep. A slice built on prototype-quality code can leave you rebuilding foundations before full production.

It depends on the game. The main drivers are team size, art style, engine, target platform, and how much of the code you want to keep.

Five mistakes come up again and again.

Polishing the wrong thing is Veronica’s menu. Publishers have limited time, so hours spent on screens nobody reaches are hours not spent on the hook.

Slicing the wrong part of the game happens when the slice is the tutorial level. A slice should contain what makes your game different, because a tutorial with no hook only shows a publisher that you can build menus.

A build that only runs on your machine is common. Test on a clean computer that isn’t yours. Missing dependencies, a different screen resolution, or no controller are the usual reasons a build works for you and for nobody else, and publishers ask for a build that’s easy to play.

An MVP with no analytics leaves you with a game that’s live and nothing to show an investor.

Passing off a prototype as a slice doesn’t help either. If your build is a prototype, say so and show the plan for the slice, because a prototype isn’t made for people outside the team.

You can build the prototype yourself; a vertical slice is where a team that has shipped before helps most, and sometimes the right answer is not to hire anyone. If one programmer on your team can test the idea quickly, an outside studio adds cost and handoff time for little gain.

A studio starts to make sense when you have the design but not the engineers or artists to hit final quality, when the pitch date is fixed, or when you want someone who has built a slice before to tell you which part to cut. It also helps when you want a firmer estimate for the full game, since a finished slice gives any team something to measure against. If you’d rather hand the heavier production work to an outside team that can take a game from prototype to launch, ask to see slices it has built before.

Whoever builds it, make sure the contract says you own the code and assets from the start, and ask for the project in a repository you control.