coss.com/ui: Cal.com's Base UI design system, copy-paste and all

What coss.com/ui solves, and for whom

Most React teams assemble a component layer from three moving parts: unstyled accessible primitives, a styling system, and a set of finished components. coss.com/ui collapses that into one repository. The README describes it as "the official Cal.com Design System" and as "a collection of beautifully designed, accessible, and composable components for your React apps," built on Base UI and styled with Tailwind CSS. The distribution model is stated plainly: "designed for you to copy, paste, and own."

The audience is narrower than the tagline suggests. This is for teams already committed to React and Tailwind CSS who want Base UI as their primitive layer and prefer to own component source rather than import it. The README also notes that this is "the component library we'll be progressively adopting for cal.com," which tells you the design decisions follow one product's needs first. If your product has different interaction patterns, you are adapting someone else's design system, not commissioning your own.

How the monorepo is put together

The repository is a Bun workspace monorepo driven by Turborepo. The root package.json declares workspaces over apps/*, apps/examples/* and packages/*, pins packageManager to [email protected], requires bun >=1.3.1 in engines, and marks the root private. Scripts are thin wrappers: build, dev, lint and typecheck all delegate to turbo run, while format and format:all call Biome directly. TypeScript 5.9.3, Biome 2.3.10, Husky and lint-staged sit in devDependencies, so linting and formatting are enforced through a pre-commit hook rather than left to CI alone.

Inside, the README lists three apps and two shared packages. apps/www is the main coss.com website, apps/ui holds the component library and its documentation, apps/origin holds the legacy Origin UI components from before the acquisition, and packages/ui holds shared components with packages/typescript-config holding TypeScript presets. Every package and app is TypeScript. The three Next.js apps are designed to link to each other, which is why each one needs to be told the others' URLs through environment variables. That cross-linking is a documentation-site concern, not a component concern, and it is the main source of setup friction.

Installing and running coss.com/ui locally

There is no published component package to install. The README gives no npm or bun add step for coss ui itself; the workflow is to clone the repository and run the monorepo. Bun 1.3.1 or newer is required by the engines field before anything else works.

git clone https://github.com/cosscom/coss.git
cd coss
bun install

Before starting the apps, each Next.js app needs a .env.local file, because navigation between them depends on absolute URLs. The README specifies these three files with these exact keys.

# apps/www/.env.local
NEXT_PUBLIC_APP_URL=http://localhost:3000
NEXT_PUBLIC_COSS_UI_URL=http://localhost:4000/ui

# apps/ui/.env.local
NEXT_PUBLIC_APP_URL=http://localhost:4000/ui
NEXT_PUBLIC_COSS_URL=http://localhost:3000
NEXT_PUBLIC_ORIGIN_URL=http://localhost:4001

# apps/origin/.env.local
NEXT_PUBLIC_APP_URL=http://localhost:4001/origin
NEXT_PUBLIC_COSS_URL=http://localhost:3000
NEXT_PUBLIC_COSS_UI_URL=http://localhost:4000/ui

With those in place, the README offers filtered dev commands so you can bring up one app instead of all three. Running the ui app should serve the component library and its documentation on port 4000 under the /ui path.

bun run dev --filter=ui

The same filtering applies to builds, for example bun run build --filter=ui. Turborepo watches .env* files, so editing an environment variable invalidates the cache automatically rather than requiring a manual restart of the pipeline. To actually use a component, copy its source out of the ui app into your own project and adjust imports; the repository is the source of truth, not a dependency you upgrade.

Origin UI is a legacy snapshot, not a second product

The most consequential detail in the README is easy to skim past. Origin UI was a pre-acquisition collection of Radix-based, shadcn-style components. It still ships in apps/origin, and the README says it "remains available for use, but with limited support and maintenance." Active development, in the project's own words, now focuses on the new Particles components built on the coss ui primitives.

That creates a fork in the road for anyone arriving from an Origin UI search. If you want the components people associate with the Origin UI name, you are adopting a frozen directory. If you want what the Cal.com team is actually building, you want the Base UI layer in apps/ui, and the primitives underneath are different. Radix and Base UI are separate projects with separate APIs, so a component copied from apps/origin will not drop into a Base UI composition without rework. The repository keeps both, but only one of them is moving.

Mixed licensing: AGPL-3.0 by default, MIT in two directories

The README states the repository "uses a mixed licensing approach" with AGPLv3.0 as the default, and the root package.json confirms AGPL-3.0-or-later. The exceptions are explicit: apps/origin and apps/ui are licensed under their original MIT license, while all other directories fall under AGPLv3. LICENSING.md is cited as the detailed reference.

This is not a formality. Copying a component out of apps/ui carries a different set of obligations than copying code from packages/ui or wiring up apps/www. The practical consequence is that you need to know which top-level directory a file lives in before you paste it into a closed-source product. The README does not explain how the boundary is enforced across shared imports, and LICENSING.md is where that question has to be answered. This is a licensing structure to read, not a legal position to assume.

How coss.com/ui differs from shadcn/ui

The obvious comparison is shadcn/ui, and the README names it directly, thanking it "for inspiring our copy-paste approach and component philosophy." So the distribution model is deliberately the same: source you own, not a package you import. The difference sits one layer down. shadcn/ui components are built on Radix primitives; coss.com/ui is built on Base UI, and the README argues that "Base UI is the best foundation for modern web applications."

That choice determines your migration cost. A team with an existing shadcn/ui codebase has Radix in its dependency tree and Radix idioms throughout its components. Moving to coss.com/ui means replacing the primitive layer, not just restyling. A team starting fresh faces a smaller decision: pick the primitive library you want to live with, then pick the design layer on top. Styling is Tailwind on both sides, so the CSS is not the differentiator. The primitive API is.

Maintenance, upgrades and what the repository does not promise

The repository is not archived, and the last push was on 2026-09-21. There are no retrieved releases, which fits the copy-paste model: there is no version to pin and no changelog to read before upgrading. Upgrades happen by pulling changes and reconciling them against the component source you already copied into your project. Anything you have customised becomes a manual merge.

Two constraints are worth stating plainly. First, the README does not document a deprecation or migration path for the Origin UI components beyond calling them legacy, so anyone depending on apps/origin has no stated timeline. Second, the README does not document rollback or version pinning for the monorepo itself. Toolchain churn is real: the root pins Bun 1.3.1 and Biome 2.3.10, and a contributor running an older Bun will hit the engines constraint before anything else. Budget for reading diffs on the components you copied, because nothing in the repository does that for you.

Editorial conclusion

Adopt coss.com/ui if you already run React with Tailwind, you accept Base UI as your primitive layer, and you are willing to read LICENSING.md before shipping, because the default AGPL-3.0 covers everything outside apps/ui and apps/origin. Do not adopt it if you need a versioned npm component package with a stable API, if you rely on Radix-based Origin UI in production (the README calls that directory a legacy snapshot with limited support), or if an AGPL obligation is unacceptable for your product. Before writing code, clone the repository, set the three .env.local files exactly as the README specifies, run bun run dev --filter=ui, and confirm which top-level directory the component you plan to copy actually lives in.

Frequently asked questions

Official sources

1. cosscom/coss on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README