# Beste UI > Beautiful, accessible blocks, pieces and components for shadcn/ui and Tailwind CSS, built for React and Next.js. Install one with the shadcn CLI and the code is yours to edit: no runtime dependency, nothing to upgrade. Markdown rendition of https://ui.beste.co/blog/13-shadcn-ui-dashboard-blocks. Every page on the site has one: add `.md` to any address, or send `Accept: text/markdown`. Last updated: 2026-07-12 Whole catalog for LLMs: https://ui.beste.co/llms.txt. Registry index: https://ui.beste.co/r/registry.json --- [All posts](/blog) July 12, 2026·10 min read # 13 shadcn/ui Dashboard Blocks: Admin Panels, Analytics, CRM, and More for Next.js Thirteen production-ready dashboard blocks built on shadcn/ui and Recharts: an admin shell, analytics consoles, a sales pipeline, a support inbox, finance, monitoring, and settings screens. Each installs with one CLI command, brings its own data table, charts, and sidebar, and exposes every visible value as a typed prop. dashboardshadcnreactnextjsadmin ![zieg](/_next/image?url=%2Fassets%2Fimages%2Fzieg.jpg&w=96&q=75&dpl=dpl_CY2dAqud5esqh3XyqpW5XSreDKej) ziegbuilding beste.co [zieg's website](https://zieg.beste.co)[zieg on X](https://x.com/forwardset)[zieg on LinkedIn](https://linkedin.com/in/ziegfiroyt) The copy-paste component model has a reputation: great for landing pages, useless past the login screen. Heroes and pricing tables paste cleanly because they are static. A dashboard is different. It has a collapsible sidebar that must survive mobile, charts that need wiring, tables with sorting and selection state, a command palette listening for ⌘K. The usual advice is to buy a template, inherit six thousand lines of someone else's architecture, and spend a week deleting. We think that advice is outdated. Today we are shipping thirteen dashboard blocks: complete, app-grade screens that install with one command, render real interactions out of the box, and hand you every visible number as a typed prop. Not screenshots of dashboards. Working ones. ### What actually installs Each block is a single React component backed by a small set of shared app components. When you install a block, the shadcn CLI resolves the whole tree: bashCopy ``` npx shadcn add "https://ui.beste.co/r/dashboard1?email=YOUR_EMAIL&license_key=YOUR_KEY" ``` That one command lands three layers in your codebase: 1. **The screen** at `components/beste/block/dashboard1.tsx`. Plain TSX you own and edit. 2. **The app components it composes** at `components/beste/component/`: things like `sidebar-nav`, `data-table`, `user-menu`, `notifications-menu`, and six chart components built on Recharts. 3. **The shadcn/ui primitives** those need (`button`, `badge`, `sheet`, `command`, `dialog`, and so on), installed only if you do not already have them. There is no runtime dependency on us. No theme object, no provider, no license check in your bundle. If you are on Base UI instead of Radix, swap `/r/` for `/r-base/` in the URL and you get the Base UI build of the same tree. Because every block composes the same shared components, installing five dashboards does not give you five sidebars. It gives you one `sidebar-nav`, one `data-table`, one chart kit, and five screens arranged on top of them. ### The frame: an admin shell in one component Most dashboard work starts with the boring part: the layout. Sidebar, topbar, account menu, notifications, search. `dashboard1` is that entire frame plus a first screen. Admin Shell [View block](/block/dashboard1) Loading preview… dashboard1: collapsible sidebar, ⌘K command palette, notifications menu, KPI row, and a sortable orders table. Everything here is live; try the sidebar toggle and the search. Look past the KPIs and notice what already works. The sidebar collapses to an icon rail on desktop and becomes a sheet drawer on mobile. The search button (or ⌘K anywhere on the page) opens a real command palette built on the shadcn `Command` primitive, fed by a `commandGroups` prop. The orders table sorts, paginates, selects rows, and exposes row actions. The notification bell and avatar menu are their own reusable components. That is the pattern for the whole set: the chrome you would normally spend the first sprint on is the baseline, not the deliverable. ### The tour Thirteen screens cover most of what product teams actually build. Every one links to a live, full-screen preview on its block page. | Block | Screen | Built around | | --------------------------------- | ------------------ | ------------------------------------------------------------ | | [dashboard1](/block/dashboard1) | Admin shell | Sidebar, ⌘K palette, KPI row, orders table | | [dashboard2](/block/dashboard2) | Customers table | One serious data table: search, sort, selection, row actions | | [dashboard3](/block/dashboard3) | Commerce analytics | Area, bar, and radial charts over a product table | | [dashboard4](/block/dashboard4) | Project workspace | Stats, weekly chart, team list, a live focus timer | | [dashboard5](/block/dashboard5) | Booking workspace | Calendar, day agenda, room availability timeline | | [dashboard6](/block/dashboard6) | Talent sourcing | Filterable talent grid with wishlist and invite states | | [dashboard7](/block/dashboard7) | Traffic analytics | Realtime strip, four chart types, top-pages table | | [dashboard8](/block/dashboard8) | Finance overview | Balance hero, budget gauge, cashflow and spending charts | | [dashboard9](/block/dashboard9) | Sales pipeline | Four-stage kanban, forecast chart, rep leaderboard | | [dashboard10](/block/dashboard10) | Support inbox | Three-pane helpdesk with a working composer and search | | [dashboard11](/block/dashboard11) | Fitness overview | Activity rings, range-switching charts, workout log | | [dashboard12](/block/dashboard12) | Service monitoring | Health grid, latency charts, 30-day uptime strip | | [dashboard13](/block/dashboard13) | Account settings | Five-panel settings: profile, security, billing, team | A few of them deserve a closer look. #### Analytics that swap datasets, not chart libraries `dashboard3` is a commerce console: four KPIs with deltas, a net-profit area chart, a repeat-purchase gauge, a busiest-weekday bar chart, and a best-sellers table. Commerce Analytics [View block](/block/dashboard3) Loading preview… dashboard3: every chart reads from a data prop, every headline figure is a string prop. Swap the arrays and the screen is yours. The charts are not bespoke Recharts code buried in the block. They are the shared chart components (`area-chart`, `bar-chart`, `radial-chart`) driven by `profitData` and `dayData` props. You change the analytics by changing arrays. #### Screens with a point of view `dashboard8` shows the set is not twelve variations of the same grid. It is a personal-finance screen with a dark balance hero, account tiles, a budget gauge, and a transaction table where income renders green and spending does not. Finance Overview [View block](/block/dashboard8) Loading preview… dashboard8: the $42,180.50 hero, the 8.4% badge, the budget gauge value and its caption are all props, so your real numbers never fight stale demo copy. `dashboard9` is a working sales pipeline: a four-stage kanban with owner avatars and hot-deal flags, revenue against forecast, and a quota leaderboard where the progress bars derive from the rep data you pass. Sales Pipeline [View block](/block/dashboard9) Loading preview… dashboard9: stages, deals, forecast series, and quota gauge all come in through props. #### Interaction is the product `dashboard10` is the block we expect people to underestimate from a screenshot. It is a three-pane support inbox where the parts you would assume are fake are not: the status chips filter tickets, the search input live-filters by subject and customer, selecting a ticket swaps the conversation, and the composer actually appends your reply to the thread (⌘Enter sends). Support Inbox [View block](/block/dashboard10) Loading preview… dashboard10: filter, search, select a ticket, type a reply, hit ⌘Enter. It all works in this frame. `dashboard13` closes the loop on the screens every app needs eventually and nobody enjoys building: settings. Five panels (profile, security, notifications, billing, team) behind a vertical section nav, with working switches, session lists, per-member role selects, and an invoice table. Account Settings [View block](/block/dashboard13) Loading preview… dashboard13: the settings screen you keep postponing, including the billing panel, driven by a billing prop. ### Every number on the screen is a prop Here is the design rule we held the whole set to: **if you can read it, you can pass it.** Each block renders its full demo out of the box, so `` with zero props looks exactly like the preview above. Every prop is optional and falls back to the demo value, which means you migrate to real data one field at a time instead of filling a giant config before anything renders: tsxCopy ``` import { Dashboard8 } from "@/components/beste/block/dashboard8"; export default function FinancePage() { return ( ); } ``` This sounds obvious until you audit dashboard templates for it. The usual failure mode is the "designed" corner: the chart takes a data prop, but the $482.6K headline above it is a string literal, so the moment you wire real data the hero contradicts the chart. We went through all thirteen screens and pulled every one of those into the props: hero figures, gauge values and their captions, uptime percentages, reminder cards, timer labels, the billing plan on the settings screen. If a number is visible, it is in the interface, typed, with the demo as its default. Two more things fall out of the demo-as-default pattern: * **Exported demo objects.** Each block exports its dataset (`dashboard8Demo`, `dashboard3Demo`, and so on). They double as documentation: the exact shape your data needs, in a file you can open. * **Readable interfaces.** `Dashboard9Props` tells you a pipeline is `stages`, `revenueData`, `reps`, `quotaValue`, `quotaCaption`. No docs site required; the props are the spec. Migrate one field at a time Start from the demo export, spread it, and override as your API comes online: ``. The screen stays complete at every step, so there is never a day when the dashboard looks broken in review. ### The app components underneath The thirteen screens are also a delivery mechanism for something quieter: a set of app-grade components that install alongside them and are yours to reuse on any screen you build from scratch. **`data-table`** is a generic, typed table: search, sorting, selection, pagination, row actions, toolbar slot, empty state. Columns are declared, not templated: tsxCopy ``` const columns: DataTableColumn[] = [ { id: "customer", header: "Customer", value: (row) => row.customer, sortable: true }, { id: "amount", header: "Amount", align: "right", value: (row) => row.amount, cell: (row) => ${row.amount}, sortable: true, }, ]; console.log(actionId, row.id)} pageSize={8} /> ``` **The chart kit** is six components (`area-chart`, `bar-chart`, `line-chart`, `pie-chart`, `radar-chart`, `radial-chart`) sharing one convention: a `data` array, an `xKey`, and a `config` object that names each series and assigns its color. Colors resolve through CSS variables, so charts follow your theme in light and dark without a JS theme bridge: tsxCopy ``` ``` **`sidebar-nav`** takes `groups` of typed items (id, label, icon, badge, optional href), works controlled or uncontrolled for both the active item and the collapsed state, and handles the icon-rail collapse styling for you. **`user-menu`** and **`notifications-menu`** are the account dropdown and notification bell every app rebuilds. And the specialty screens contribute their own reusables: `calendar-month`, `schedule-timeline`, and `talent-card`. ### The details you would have had to build twice A dashboard template is easy to demo and hard to live with. These are the living-with-it details the set already handles: * **Server rendering is safe.** No `Date.now()` or `Math.random()` in render paths, timers seed deterministically and start in effects, calendar state uses fixed dates. The screens hydrate without mismatch warnings. * **Mobile is not an afterthought.** Shells collapse to icon rails and sheet drawers; grids reflow; the booking workspace splits its panes. * **Keyboards work.** ⌘K opens palettes globally, ⌘Enter sends replies in the inbox, icon-only buttons carry `aria-label`s, switches and menus are the accessible shadcn primitives underneath. * **Theming is token-based.** Everything reads from your CSS variables (`background`, `card`, `chart-1` through `chart-5`), so the blocks adopt your brand and your dark mode the moment they land. * **The code is yours.** No wrapper package to fork when you hit the inevitable custom requirement. It is TSX in your repo, structured the way you would have written it on a good day. ### Start with the frame, swap in screens The set is designed to be combined. A practical route for a new product: 1. Install `dashboard1` and make it your app frame: your nav groups, your command palette entries, your user menu. 2. Drop screens behind routes as features ship: `dashboard2` for the customers page, `dashboard3` or `dashboard7` for analytics, `dashboard13` for settings. 3. When you outgrow a screen, you are not starting over. You are rearranging the same `data-table`, chart kit, and nav primitives the blocks themselves are made of. Since every block declares its dependencies, the CLI keeps this cheap: shared components install once, and each new screen is an incremental add. Ship the admin panel this week All thirteen dashboard blocks, the data table, the chart kit, and every other Pro block are included in one license. Install them straight from the CLI and own the code. [Get ProGet Pro](/pricing) ## Build it with real blocks Every section in this post is a component you can copy into your own codebase and own outright. [Browse blocksBrowse blocks](/blocks)[Read more postsRead more posts](/blog) ## Ship the interface, keep the code. New blocks, pieces and components every week. Install one with a command and it is yours to edit. No runtime dependency, no upgrade path to fight. [Browse the libraryBrowse the library](/blocks)[See pricingSee pricing](/pricing) ### Library * [Blocks](/blocks) * [Pages](/pages) * [Pieces](/pieces) * [Components](/components) * [Search](/search) ### Learn * [Docs](/docs) * [AI & MCP](/docs/mcp) * [Blog](/blog) * [Free tools](/tools) * [What's new?](/changelog) * [Website Builder](https://beste.co) ### More * [Pricing](/pricing) * [Referrals](/referrals) * [License](/license) * [GitHub](https://github.com/beste-co/beste-ui) ### Shadcn Blocks * [Shadcn Hero Blocks](/blocks/hero) * [Shadcn Feature Blocks](/blocks/feature) * [Shadcn Pricing Blocks](/blocks/pricing) * [Shadcn CTA Blocks](/blocks/cta) * [Shadcn FAQ Blocks](/blocks/faq) * [Shadcn About Blocks](/blocks/about) * [Shadcn Stats Blocks](/blocks/stats) * [Shadcn Footer Blocks](/blocks/footer) * [Shadcn Navigation Blocks](/blocks/navigation) * [Shadcn Auth Blocks](/blocks/auth) * [Shadcn Ecommerce Blocks](/blocks/ecommerce) * [Shadcn Portfolio Blocks](/blocks/portfolio) * [Shadcn Showcase Blocks](/blocks/showcase) * [Shadcn Careers Blocks](/blocks/careers) * [Shadcn Onboarding Blocks](/blocks/onboarding) * [Shadcn Coming Soon Blocks](/blocks/coming-soon) * [Shadcn Post Blocks](/blocks/post) * [Shadcn Legal Blocks](/blocks/legal) * [Shadcn Workflow Blocks](/blocks/workflow) * [Shadcn News Blocks](/blocks/news) © 2026, [Beste](https://beste.co). All rights reserved.