MOCs vs Projects: What's the Difference?
MOCs and Projects both live under the Build area of BrickZap, but they answer different questions.
MOC means "What is this build?" It is the design. Project means "How is my build of it going?" It is your personal build log and workspace.You can have many Projects for one MOC when many people are building the same design. One user can also have many Projects, each tied to a different MOC, or to no MOC at all.
Quick comparison
PurposeMOC: the design, or what to build.
Project: your build, or how it is going.
AnalogyMOC: a recipe.
Project: cooking that recipe in your kitchen.
OwnershipMOC: one creator; many people can build it.
Project: one builder; private to that builder unless shared.
CardinalityMOC: one MOC can have many Projects.
Project: one Project can link to zero or one MOC.
Source of truthMOC: parts list, build steps, model graph, and assets.
Project: owned parts, progress, photos, updates, and sourcing.
Created fromMOC: a Studio .io upload.
Project: a MOC, an inventory file such as BSX or CSV, or from scratch.
InventoryMOC: canonical BOM, which is what the model needs.
Project: your snapshot, which tracks what you have and what is missing.
Mutable inventoryMOC: only through re-importing the design.
Project: yes, you update owned counts as you build.
Visibility scopeMOC: discoverability of the design.
Project: discoverability of your build.
Public catalog routeMOC: /marketplace/mocs/public/{slug}.
Project: /marketplace/projects/public/{handle}/{slug}.
MOC: no; people follow builders and Projects, not designs.
Project: yes, other users can follow your build.
Status, progress, and updatesMOC: no status, progress percentage, or build updates.
Project: has status, progress percentage, and build updates.
Files and cover imageMOC: design assets such as thumbnails, textures, embedded files, and a cover image for the design.
Project: user-uploaded instructions, build photos, notes, and a cover image for this build.
SourcingMOC: does not directly affect Add to cart or sourcing.
Project: missing parts can be added to cart or a wanted list.
Build stats and deletionMOC: does not count toward your build stats, and deleting a MOC does not delete Projects derived from it.
Project: counts toward your build stats, and deleting a Project does not delete the MOC.
What lives on a MOC
A MOC is the design record. It can include:
- Metadata such as title, slug, description, cover image, tags, difficulty, estimated cost, and source ID
- Author information, creator user ID, and visibility
- Studio model graph from the
.ioparse - Submodel hierarchy
- Ordered build steps
- Per-step part placements, including SKU, color, position, and rotation
- Embedded assets such as thumbnails and textures
- Model-level metadata such as author, license, and keywords
- Parse status, parser version, and source file hash
- Canonical inventory from
MocInventoryItem, which is the full BOM derived from placements - Rollups such as total parts, unique parts, total steps, total submodels, total placements, total assets, and project count
What lives on a Project
A Project is your build workspace. It can include:
- Metadata such as name, slug, description, cover image, visibility, and status
- Status values such as planning, sourcing, building, completed, or paused
- Builder identity linked to your user and, when public, your builder profile handle
- Owned vs needed inventory from
ProjectItem - Required quantity, manually owned quantity, and computed missing quantity for each row
- Progress totals such as total parts, owned parts count, missing parts count, completion percentage, and last activity date
- Build updates from
ProjectUpdate, including timestamped posts, photos, and progress notes - Followers from
ProjectFollow - Files from
ProjectFile, such as instructions, photos, and attachments - An optional MOC link through
moc_idandsource_type = 'moc'
If a Project has no MOC link, it is a custom Project.
How they interact
A MOC can exist without any Project. It is simply a design in your library or in the public catalog.
A Project can exist without a MOC. You can build something custom without publishing or importing a design.
A MOC plus a Project is the common pair: someone created the design, and you are now building it.
When a Project is created from a MOC, the Project receives an independent snapshot of the MOC inventory:
ProjectItemrows are copied fromMocInventoryItemrows at that moment- Later MOC inventory changes do not propagate to existing Projects
- Changes to Project owned counts do not write back to the MOC
This is intentional. The design is a stable reference, and your Project is a personal workspace.
Who each one is for
MOC consumers want to find builds and try them. They browse public MOCs, view the design, and start a Project. MOC creators want to share designs. They upload a.io file, write a description, and publish the MOC.
Project owners want to track a build. They manage owned parts, log progress, source missing pieces, and share updates.
A single user is often both a Project owner and, sometimes, a MOC creator.
Common UI patterns
- Build this MOC on a MOC detail page creates a new Project linked to that MOC
- View design on a Project page routes to the underlying MOC, when one is linked
- Public MOC cards show design information and a build count badge from
moc.project_count - Public Project cards show the builder handle, status, completion percentage, and a link back to the MOC when linked
- My library separates MOCs you created from Projects you are building
Visibility recap
MOC visibility controls who can see the design.
Project visibility controls who can see your build.
They are independent and are not inherited from each other. For the full visibility matrix, see Project Visibility and Sharing.
TL;DR
A MOC is what to build. A Project is you building it.
One is shared knowledge. The other is your personal workshop.