Mavizo

Mavizo separates the parts of a store that change for different reasons. Medusa owns products, orders, payments, and fulfillment. Sanity owns articles and marketing pages. The Next.js apps read from both.

What lives in the monorepo

mavizo/
├── apps/
│   ├── mavistra-medusa/             # Medusa commerce backend
│   ├── mavistra-medusa-storefront/  # Storefront connected to Medusa
│   ├── mavistra/                    # Next.js and HeroUI app
│   ├── mavizo/                      # Next.js app
│   └── cms/                         # Sanity Studio
├── packages/
│   ├── ui/                          # Shared components
│   ├── shared-assets/               # Shared static files
│   ├── eslint-config/               # Shared lint rules
│   └── typescript-config/           # Shared TypeScript settings
└── turbo.json

Turborepo and pnpm keep the apps in one workspace. Shared components and configuration live under packages, so a storefront does not need to copy the same UI or compiler settings from another app.

Why it is split this way

Commerce stays in Medusa

Medusa provides the usual commerce flows while leaving the modules open to change. Product and order rules stay in the backend instead of leaking into a storefront or being tied to a hosted shop builder.

Editorial content stays in Sanity

An article is not a product record. Sanity gives content editors a separate place to change pages and posts without touching the catalog or deploying a frontend.

The apps share foundations, not screens

The apps share TypeScript settings, lint rules, assets, and reusable UI. They can still choose the layout and components that fit their part of the product. One of the Next.js apps uses HeroUI and Framer Motion, but those choices do not become requirements for every package.

This structure costs more setup than a single Next.js app. It pays off only when the storefront, main site, CMS, and commerce service need to move independently.