Most small businesses are flying blind. They know their revenue number. Maybe their expenses. Beyond that, the data that could tell them where their leads are leaking, which marketing channel is actually converting, or what their client retention rate really is — that data exists. It's just scattered across five different tools with no way to see it in one place.

The solution isn't a $2,000/month enterprise BI platform. It's a custom dashboard built for their specific business, showing the specific numbers that matter to them, with data from the specific tools they already use. And Claude and I can build that in a weekend.

The Stack

Every dashboard we build runs on the same base: Next.js 16, React 19, Tailwind CSS 4, and shadcn/ui components. It's deployed on a Linux server with nginx as a reverse proxy and systemd managing the Node process. SSL from Let's Encrypt. HTTP Basic auth for admin routes.

Why this stack? Because it's fast to build on, the component library covers everything a dashboard needs (tables, charts, cards, tabs, drawers), and the deployment pattern is reliable enough to run production workloads without breaking. We've deployed the same base to six different clients. Each dashboard looks different. The infrastructure is identical.

Fork, Rename, Customize

The build process starts with a fork of the base template. Copy the directory, update the color scheme (Tailwind CSS variables), drop in the logo, change the sidebar labels to match the client's actual business vocabulary. That's Day 0 — maybe two hours, including the first deploy to a staging URL.

The client can see something running on day one. That matters more than you might think. Clients who can see their actual branding in a running interface give better feedback faster. They stop talking about color preferences and start talking about what data they actually need.

Real Builds

Here's what we've shipped with this workflow:

• Practice Sys Console — Operator dashboard for a dental practice management consultancy. 411 Portland dentist leads, a full outreach module with Resend email integration, a client roster with stage tracking, and a competitor analysis section. Live at psys.nwesource.com.
• Revolution Marketing Console — Marketing intelligence dashboard for a dental implant center. Conversion tracking with CPL by campaign, Scale/Keep/Watch/Fix/Kill verdicts, funnel analysis with leak pricing in real case dollars. Lead-gen attribution down to the marketing-vs-operations level.
• Hero Fence Hub — Wix lead-to-Square-customer sync automation dashboard for a fence contractor. Webhook triggers, lead capture, customer conversion tracking, and a proposal pipeline view.
• Sylvie Outreach Console — Email outreach platform for a dental hygienist building her practice. ZIP-centroid distance sort on 411 leads, multi-select send via Resend, open/click tracking, sent log.

Each of these took one to three days of active build time. The rest of the timeline is iteration based on client feedback.

Where AI Fits in the Build

Claude is the pair programmer throughout. Not a code generator that produces scripts to paste — an active participant in the build who understands the full file tree, tracks what's been built, and catches inconsistencies before they become bugs.

The pattern looks like this: I describe what a module needs to do ("a leads table with stage filter, click-to-modal detail view, and inline edit for the primary contact"). Claude writes the component, the API route, and the data types in one pass. I review, deploy, and we iterate from the running version.

What makes this fast isn't that Claude writes faster than I type. It's that the feedback loop is compressed. There's no ticket, no spec document, no handoff to a dev who interprets the spec differently. The person who understands the requirement and the person building it are in the same conversation.

Connecting Real Data

The hardest part of dashboard work isn't building the UI. It's connecting real data. Every client uses different tools and every tool has a different API.

The pattern we've developed: start with whatever data the client can export manually (CSV from their CRM, PDF from their ad platform). Build the dashboard around that data structure. Once the interface is validated — once the client is using it and finding it useful — then build the API integrations to automate the data flow. Don't build integrations for a dashboard nobody's using yet.

What Clients Actually Get

A custom dashboard that runs on their subdomain (dash.theirdomain.com), shows their data, uses their branding, and includes only the metrics that matter to their specific business. No onboarding, no per-seat pricing, no feature flags that require an enterprise plan. Just a running web application that belongs to them.

The data stays theirs. The code stays theirs. If they want to change something six months from now, they're not locked into a vendor. That's what "custom" means in practice.