# Taxonomy: An Archived Next.js 13 App Router Reference Application

> Taxonomy is a reference application by shadcn that explored Next.js 13's App Router, server components, and associated tooling when the framework was in public preview. The README states the project has been officially archived and is not recommended for production use, as it may contain deprecated APIs and does not reflect current Next.js best practices.

**shadcn-ui/taxonomy** — An open source application built using the new router, server components and everything new in Next.js 13.

- Repository: https://github.com/shadcn-ui/taxonomy
- Stars: 19,293 · Forks: 2,744
- Language: TypeScript
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/shadcn-ui-taxonomy

## What Taxonomy Is and Why It Was Built

Taxonomy was created by shadcn as an experiment to see how a modern full-stack web application would work using the Next.js 13 App Router when it was in public preview. The README describes the goal as testing features like authentication, subscriptions, API routes, and static documentation pages within the new App Router architecture.

The project is not a library or a tool: it is a demonstration application. Its value is showing how specific technologies integrate with each other inside the App Router model, not providing reusable components or a deployable product. The application includes a marketing site, a blog powered by MDX, a documentation section, user authentication, and a subscription flow.

The README explicitly notes that the project has been officially archived and will no longer receive updates. The author states that because the Next.js App Router has since stabilized and undergone significant architectural changes, the code in Taxonomy does not reflect current best practices, may contain deprecated APIs or patterns, and is not recommended for production environments. This is the most important fact about the repository: it is a snapshot of an experimental phase in Next.js history, not a current reference.

## How the App Router Structure Is Laid Out

The repository uses the Next.js 13 App Router convention, where page components live under the app/ directory rather than the older pages/ directory. The top-level layout shows both app/ and pages/ directories present simultaneously, reflecting the transitional period when Taxonomy was built. Both directories are listed in the repository tree.

Content for the blog and documentation is processed through Contentlayer and MDX. The contentlayer.config.js file at the root configures the content layer, and content/ holds the MDX source files. The dev script in package.json runs contentlayer dev and next dev in parallel using concurrently, which is necessary because Contentlayer processes MDX files at dev time and must run alongside the Next.js development server.

The app/ directory follows the Next.js 13 file-system routing conventions: layouts, loading states, and route handlers live in subfolders alongside their page.tsx files. The hooks/, lib/, and components/ directories at the root hold shared logic and UI components. The config/ directory holds site-wide configuration.

Because the App Router has changed since Taxonomy was built, the specific patterns in the app/ directory may not match the current Next.js documentation. Developers reading Taxonomy's code to understand current App Router conventions should cross-reference against the official Next.js documentation rather than treating this codebase as authoritative.

## Running Taxonomy Locally

The README gives three steps to run the application locally. First, install dependencies with pnpm:

```sh
pnpm install
```

Second, copy the environment variable template and fill in the required values:

```sh
cp .env.example .env.local
```

Third, start the development server:

```sh
pnpm dev
```

This runs both the Contentlayer dev process and the Next.js development server in parallel. The application is accessible at http://localhost:3000 by default.

The .env.example file reveals what credentials the application requires: a NextAuth secret and a GitHub OAuth app (GITHUB_CLIENT_ID and GITHUB_CLIENT_SECRET), a MySQL database URL pointing to a PlanetScale-compatible database, Postmark email credentials for transactional email, and Stripe API keys for the subscription flow. None of these are optional: the application will not start or function without valid values for each service.

The database connection string in .env.example uses the format mysql://root:root@localhost:3306/taxonomy. In the original setup, PlanetScale provided the MySQL-compatible database, but PlanetScale has since shut down its free tier and changed its pricing model. A developer running Taxonomy today would need to substitute a local MySQL instance or a compatible alternative.

## The Integration Stack: Prisma, PlanetScale, Stripe, and NextAuth

Taxonomy integrates several services that each require configuration before the application functions. Prisma serves as the ORM, with the schema in prisma/ and the postinstall script in package.json running prisma generate automatically after dependency installation. The Prisma schema targets a MySQL-compatible database, which in the original setup was PlanetScale.

Authentication is handled by NextAuth.js with the @next-auth/prisma-adapter package connecting it to the Prisma-managed database. The .env.example file shows that GitHub OAuth is the configured provider, along with a generic email flow. The README notes that GitHub authentication was not working at the time of archival.

Stripe handles subscriptions, with the stripe npm package and a configured STRIPE_API_KEY and STRIPE_WEBHOOK_SECRET. The STRIPE_PRO_MONTHLY_PLAN_ID environment variable identifies the plan in the Stripe dashboard. The application does not create plans programmatically; the plan must exist in the Stripe account before the subscription flow works.

Content for the blog and documentation uses MDX processed by Contentlayer. The contentlayer.config.js file at the root defines the content types and their metadata fields. Radix UI primitives handle accessible interactive components, and Tailwind CSS handles styling. Zod validates environment variables and form inputs.

This integration density is one reason Taxonomy was useful as a reference when it was built. A developer seeing how all of these pieces connect in a single application saved significant time. The cost is that any breaking change in any of these integrations renders part of the code incorrect, and several such changes have occurred since Next.js 13 was in preview.

## Why Taxonomy Is No Longer the Right Reference

The README's own note says the code does not reflect current best practices, may contain deprecated APIs or patterns, and is not recommended for production environments. This is not a minor caveat: the Next.js App Router changed significantly between its preview phase and its stable release, and changes to server component patterns, data fetching APIs, and route handler conventions are documented in the Next.js upgrade guides.

Several of the integrations have also changed since Taxonomy was built. PlanetScale changed its pricing model, removing the free tier that made it the obvious starting database. Contentlayer has had periods of reduced maintenance activity. The next-auth package has released version 5, which introduces breaking changes relative to version 4. A developer who copies Taxonomy's approach to authentication will need to migrate the NextAuth configuration to the current API.

The known issues in the README include a problem with opengraph-image.tsx inside catch-all routes, which was open as of the last update and references a Next.js issue. This category of issue exists because Taxonomy was testing edge cases of a framework in preview, and not all of them were resolved before the repository was archived.

## License and Archive Status

Taxonomy is released under the MIT license, which permits use in any context without restriction. The license file is at LICENSE.md in the repository root.

The last push to the repository was on 2026-04-20. The README states the project has been officially archived. The Vercel Templates directory at vercel.com/templates/next.js is listed in the README as the current recommended starting point for Next.js applications. Taxonomy's own codebase is available for reference, but the author has moved on from maintaining it.

For developers who want to see how shadcn's current approach to React UI components is structured, the shadcn/ui repository is the active project. Taxonomy predates shadcn/ui as it currently exists and uses Radix UI primitives directly rather than through the shadcn/ui component layer.

## Conclusion

Developers curious about how the Next.js App Router was implemented in a full-stack application before the framework stabilized will find Taxonomy useful as historical context. Anyone looking for a starting point for a new project should not use Taxonomy: the README explicitly states the code does not reflect current best practices, may contain deprecated APIs, and is not recommended for production environments. The Next.js documentation and the Vercel Templates directory at vercel.com/templates/next.js are the current recommended starting points.

## FAQ

### Is the Taxonomy repository still safe to use as a project starter?

The README explicitly states Taxonomy is not recommended for production environments, as it may contain deprecated APIs and does not reflect current Next.js best practices. The Vercel Templates directory at vercel.com/templates/next.js is the recommended alternative for starting new Next.js projects.

### What environment variables does Taxonomy require to run locally?

The .env.example file shows that Taxonomy requires a NextAuth secret, GitHub OAuth credentials, a MySQL database URL, Postmark email credentials, and Stripe API keys including a plan ID. All of these must be configured before the application can start and function.

### Why does Taxonomy run both contentlayer dev and next dev at the same time?

The dev script in package.json uses concurrently to run contentlayer dev and next dev in parallel because Contentlayer processes the MDX blog and documentation content at development time. Without the Contentlayer process running, the application cannot read the content files.

## Sources

- [Issues](https://github.com/shadcn-ui/taxonomy/issues)
- [License: MIT](https://github.com/shadcn-ui/taxonomy/blob/main/LICENSE)
- [README](https://github.com/shadcn-ui/taxonomy/blob/main/README.md)
- [shadcn-ui/taxonomy on GitHub](https://github.com/shadcn-ui/taxonomy)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/shadcn-ui-taxonomy