Demo project
Store admin panel: TemplateForge
Overview, orders, customers and price settings - the back office of a Notion template store.
development · Next.js 15 · TypeScript · Tailwind · Zustand · Recharts

The task
TemplateForge is a Notion template store from a neighbouring demo: ten templates, a storefront, a cart, checkout. This panel is the same store from behind the counter. The owner opens it in the morning and wants to see in a minute how much came in, what sells, who came back for a second purchase, and whether a price needs changing. The company is fictional, the brief ordinary. It is a working tool, not a showcase: density and split-second status reading beat whitespace.
One requirement comes from the pairing: the panel has to agree with the storefront. These are two independent static demos with no shared code and no shared server - they agree on data. The catalog, names, categories and prices are copied from the store project verbatim: if Focus OS costs $29 here, it costs $29 on the storefront. The catalog is pinned by a test: ten ids, names, prices and categories checked row by row.
The solution
Five working screens - overview, products, orders, customers, settings - plus a login and a disclaimer page. Next.js 15 with static export, state in Zustand, no backend: everything runs in the browser.
- Overview: eight metrics for the period - revenue, orders, average check, conversion, net revenue, storefront visits, refunds, buyers. Each carries a sparkline, and seven of the eight also carry a comparison with the previous period of equal length. With nothing to compare against, the panel says so instead of drawing “+100%”.
- The reporting period switches in the header: 7, 30 or 90 days. Everything recalculates, from the revenue chart to customer segments.
- Orders: 1,263 records in the 90-day dataset, a status filter with counters, search by number, name or email, sortable columns, pages of 20 rows. The order card holds contents, a step-by-step status history and the refund button.
- Refunds follow the store’s own rule: a paid order no older than 14 days. Outside that window the button is disabled and the reason is spelled out.
- Products: ten templates with sales and revenue for the period, a category filter, a card with two badges: the editorial one (BESTSELLER, NEW) and a computed “new arrival”.
- Customers: segments by order count, weekly return cohorts, refunds by template, a table with search and sorting.
- Settings: price editing, the category reference, promo codes - switching them on and off, adding one with format and discount checks.
- Every change is confirmed by a toast with an undo button: price, badge, refund and promo code roll back in one click.
Details that are easy to miss
- The data is deterministic: a custom seeded generator, and “now” is a constant, not the current clock. A test compares the dataset byte for byte - by length and by sha256 - so screenshots reproduce exactly.
- The last bar of the revenue chart is labelled a partial day: the fixed “now” is noon, so that day holds only twelve hours of sales. Without it the chart would read as a collapse.
- A template never appears in an order placed before it entered the catalog: Study Hub shows up from 15 July, Thesis Track from 8 August.
- Segments are computed inside the selected period, not across the whole history. Switching the period recomputes them, and the interface says as much.
- In the weekly cohorts the return share drops toward the right edge: recent buyers had less time to come back. A caption says so under the chart, otherwise it would read as falling retention.
- There is always exactly one undo button. Review caught a defect: after two actions in a row two toasts offered undo, yet both rolled back only the last. A new action now strips undo from older toasts.
- Loading, empty and error states are triggered by a URL parameter, so they can be shot and checked. On the overview an empty period zeroes the KPI tiles, not just the table. So far the automated run covers those three states on the settings screen; the other screens are manual items.
- The login is honestly demonstrative: credentials are prefilled, the check runs on the client, the session lives in the tab. It shows access separation without pretending to be security.
- Demo legal hygiene: a line about demonstration materials in the menu, a disclaimer page, no-index in the metadata and in the deployment headers.
- One theme, dark, on purpose: this store’s world exists only in it. There is no separate mobile layout: the panel is built for 1440, 1024 and 768 pixels and shot at those widths.
What is left
The automated checks pass in full: build, types, tests and a scripted walk over every screen. Four test-plan items are marked manual and stay with a human: a visual read of the screenshots, the add-promo form, a wrong password plus signing out, and demo states on the remaining four screens.
Screenshots




