Big Slice / Small Slice (BSSS): Updated Rules and Recommended Allocation

By Matt Paulin

Big Slice / Small Slice (BSSS)

BSSS Companion Guide

The General Idea

When working with friends on projects I always run into the problem that everyone has hidden expectations about ownership and what it means to be successful. Many of us don’t even know that we have these expectations. They are based on how we were raised and what we value. Thus they are very personal, hidden, and can easily destroy a friendship if you become successful. On the flipside of this is the overthinking that happens from creating shares too early. It cost a real money, momentum, and energy to create shares and a vesting schedule. Suddenly that playful idea feels like work and it kills the joy of creation with adulting.

Therefore I invented these rules as insurance against the misscomunications that form when we all are excited to build something and don’t want to think about how much of nothing each of us will own… Until it isn’t worth nothing.

The Big Slice / Small Slice idea originated as a design pattern for allocating ownership dynamically and transparently in early ventures. It was first described as a way to prevent resentment, hidden dilution, and retroactive negotiation when teams were contributing unevenly under high uncertainty.


Vocabulary

Big Slices

A Big Slice represents a major milestone in the life of a project.

Each Big Slice:

  • Consumes a declared percentage of the total 100%
  • Is tied to a specific Release Level (RL1–RL10)
  • Has a point budget for contribution tracking
  • Opens when work begins
  • Closes when the Release Level is achieved

Critical rule:
Once a Big Slice is created, its percentage must never change.

Point budgets may increase.
Ownership percentages may not.


Small Slices

Contributors earn Small Slices inside a Big Slice.

A Small Slice represents a contributor’s proportional share of that Big Slice, calculated as:

(points earned / total points in the Big Slice) × Big Slice percentage

When a Big Slice closes, ownership earned inside it is locked.


The Rules

Rule 1: Treat ownership as a fixed whole:

A project begins as 100% ownership. Think of a pie. Now budget out what milestones the project is going to go through. Set a percentage to each milestone and lock that down with your group.

Rule 2: Track effort from each contributor in each phases

The philosophy is that progress earns ownership, time alone does not.

You can track hours, you can use dubloons, you can track happy points, it doesn’t really matter. I prefer to use a point system because then effort like sales or connections can be trued up against hours. Sales, networking, and engineering work very differently and the contributions are not equivalent.

I think the easiest way to do this is to setup a regular meeting where everyone involved shows up and says how many points they contributed to this project. Then the group agrees or debates it, and records the decision in a journal. This turns one giant akward discussion into lots of little akward discussions.

Rule 3: At the end of each Big Slice (milestone) tally up the small slices.

Ownership is divided into:

  • Big Slices — milestone-level allocations
  • Small Slices — individual shares earned within a milestone

So at the end of each milestone tally up how many points each contributor made and then proportinaly split up the big slice they just worked through. Then move onto the next phase.

That ownership is not assigned to people upfront. Instead, it is earned over time as the project progresses through meaningful milestones.


The following table represents a recommended allocation of ownership across Release Levels.

This is not universal law.
It is an opinionated default that reflects where risk and value tend to concentrate.

Release Level Description Slice %
RL1 Idea 4%
RL2 Vision 4%
RL3 Prototype 4%
RL4 Play Test 12%
RL5 Release 16%
RL6 Users 12%
RL7 Audience 12%
RL8 Monetized 12%
RL9 Scalable 12%
RL10 Stable 12%
Total   100%

Regarding this Allocation Philosophy

  • Early stages matter, but are highly speculative
  • Mid-stage execution carries the highest product risk
  • Late stages reward durability, scale, and operational excellence

To Conclude

What This Is (and Is Not)

This system is:

  • A contribution accounting model
  • A milestone-based ownership framework
  • A pre-equity alignment tool

This system is not:

  • Legal equity
  • A cap table
  • A shareholder agreement

It is a bridge between ambiguity and formality. Assuming success then you can transition to something more formal like a captable and preferred shares. But until then it can just be a spreadsheet.


Bonus

I did build this into my system on The Idea Is in case you want to use it when you get to the implementation level.