Nexora Marketplace

What a prototype proves

Component libraries get demonstrated on a landing page and a signup form, which is not where they come apart. They come apart on dense screens: filterable tables, analytics charts, multi-step forms, a sidebar carrying a different information architecture for each audience. I wanted somewhere to put shadcn/ui under that load and see what was missing. Holding all three roles in one repository is what makes the question answerable at all. Two of those roles are still empty, and that is exactly where the work would resume.

One dense screen

app/(app)/seller/dashboard/page.tsx is barely twenty lines. It wraps SidebarProvider and AppSidebar around SiteHeader, SectionCards, ChartAreaInteractive and DataTable, setting --sidebar-width and --header-height as inline custom properties. The layout is driven by container queries rather than the viewport, so @xl/main and @5xl/main size the card grid from the width of the main region instead of the window. SectionCards renders four metric tiles with hardcoded figures and trend badges. The chart is Recharts inside the shadcn ChartContainer. Every number on that page is a literal in the component, which is what a prototype should be.

Inside the table

components/data-table.tsx carries most of the weight. It uses TanStack Table with sorting, column filters, faceted unique values, pagination and a column visibility menu. Rows drag through dnd-kit, with restrictToVerticalAxis, a SortableContext on the vertical list strategy and arrayMove on drag end. Opening a row reveals a Drawer holding its own small Recharts area chart, so detail and summary share one visual language. The row shape is a Zod schema of id, header, type, status, target, limit and reviewer. That shape is the giveaway. It is the shadcn sample dataset, sixty-eight rows of document review, sitting where seller orders belong.

Choices worth naming

• One repository for three roles, because that is what exposes where navigation genuinely has to diverge. It also leaves one sidebar component with three unbuilt variants, and app-sidebar.tsx still ships the shadcn demo navigation with every url set to #.
• Mock data instead of a backend. A screen changes without a migration behind it, and layout questions get answered in an afternoon. Nothing here has ever survived a reload, so state, latency and empty results stay untested.
• Container queries rather than media queries for the dashboard grid. A card block then behaves the same wherever it is placed, which matters when the same block has to sit inside three different shells. It is also harder to reason about from the markup alone.
• The auth screens are layouts, not flows. login-form.tsx gates its next step on a regex email check, and its form still submits nowhere. React Hook Form and Zod are in the dependency list and in none of those three files. I would revisit that first, because a six-digit OTP input is where validation and error states earn their keep.

Running it

pnpm install and then pnpm dev bring the whole thing up on port 3000, with no environment variables and no services to start. What sits behind each route is uneven.

pnpm build, pnpm lint and pnpm format:check are the rest, and a husky pre-commit hook runs pnpm lint-staged.

Where it stops

There is no backend, no persistent authentication, no payments, no inventory and no fulfilment. The README puts that under a project status heading rather than implying otherwise. The privacy and terms pages do carry written policy text, which the same README declines to warrant for a deployed service, and SECURITY.md exists mostly because the repository is public. Alongside the screens the project carries a hook and utility library: use-local-storage, use-media-query, use-debounce, timezone and date helpers, and a small MDX parser. It runs on Next.js 16, React 19, Tailwind CSS 4 and shadcn/ui, ships a Dockerfile, and is MIT licensed.