Most agencies show you mockups and case studies with the client name stripped out. That is fine when NDAs require it, but it leaves a gap. You never get to see how the developer thinks when nobody is watching. I use this site as the fill-in for that gap. The journal, the contact pipeline, the admin console, the flags, the sitemap refresh, the image checks — all of it is real code in a real repo, deployed to a real hostname. You can read the field notes, submit the contact form, and watch the network tab while the home page loads. That is intentional.
\n\nThe design is deliberately sharp: black field, acid accent, no component library pretending to be a brand system. I write vanilla CSS because I do not want a framework fighting me on every layout tweak, and I do not want future-you paying rent on abstractions you never needed. React handles structure and state. CSS handles the visual system. The split stays clean.
\n\nIf you are comparing vendors, ask where their reference build lives. If the answer is a Dribbble shot and a PDF, you are buying a promise. This site is the working proof I point to when NDAs hide everyone else's logo.
\n\n./deploy.sh prod\n# build → prerender shells → sync dist → sitemap → image verifyThe public app runs on React 19 with Vite. Routes are split so the journal and portfolio chunks do not land on the contact page. The home page loads the hero and trust sections first; heavier bands like the project grid and journal strip wait until the browser is idle. That is not a marketing trick. It is how you keep Largest Contentful Paint from losing to your own enthusiasm for features.
\n\nI still write components the old-fashioned way: functions, props, local state where it belongs. I am not importing a state library to toggle a contact form. The React Compiler is on the roadmap for the same reason it matters on client work — less manual memoization, fewer “why did this child re-render” rabbit holes. For now the code stays readable on purpose. If you open the repo, you should recognize patterns you could maintain.
\n\nPer-route HTML shells exist for the main public URLs. Crawlers and link previews get real titles and descriptions without running the full client bundle first. Journal posts ship a prerender body in the shell so view-source is not a thin placeholder. In-flow routes like /about and /services get SSR hero markup and critical CSS before hydration. The SPA still hydrates for humans; the shell is there for machines and first paint.
PageSpeed discipline is not an afterthought here. Stylesheet before module script in index.html. Hero LCP gated so the prerender portrait drops only after paint. Public API reads use edge-friendly cache headers — not no-store on every JSON call. When I publish a PSI screenshot on the home page, it is from a run I can reproduce on briancrabtree.me with a date attached.
A mistake I see constantly is wiring the marketing site directly to a database SDK from the browser on every page load. That couples your first paint to a third-party client, your access rules, and whatever latency the backend feels like that day. Here, public pages call /api/public/* routes on a Node process (staging-ai-proxy on 127.0.0.1:3005) backed by self-hosted PocketBase.
The CMS instance is site-pocketbase: PocketBase listening on 127.0.0.1:8092, data on disk at /www/wwwroot/site_pb_data. It is not a managed SaaS add-on. It is a Docker container on the same VPS as nginx and the API proxy. That keeps latency predictable and keeps my content under my control.
Collections that power the public site include:
\n\nposts — journal entries (slug, title, summary, HTML body, featured flag)projects — portfolio cards and case-study fields (problem, build, outcome)testimonials — NDA-safe outcome records, not stock headshots with fake namesfaqs — pricing and process copy for the contact flowsite_content — hero, footer, announcement bar, system flags as keyed JSON blobsmessages and form_leads — contact pipeline with attributionPublic routes return sanitized summaries only. Portfolio cards expose stable public IDs via legacy_firebase_id (a migration artifact — the field name stuck, the data lives in PocketBase now). Testimonials on the home page are outcome chips with proof types, not anonymous praise. Likes and view counts adjust through dedicated public endpoints (POST /api/public/like, view increment on read) — not through admin form saves that could accidentally zero engagement.
Representative public endpoints you can curl without credentials:
\n\n/api/public/home-posts and /api/public/home-projects — curated lists for the home page/api/public/projects and /api/public/posts — full public catalogs/api/public/posts/:slug — single journal article/api/public/testimonials and /api/public/faqs/api/public/site-config/:section — hero, footer, announcement bar/api/public/system-flags — maintenance mode, WebGL toggleContact submissions write to PocketBase and trigger a server notify path. Attribution refs from the URL survive so I can tell which CTA sent the brief. That is boring plumbing, and boring plumbing is what stops leads from dying in a mailbox you forgot to check.
\n\nThe admin app is not a separate product bolted on later. It lives at /admin in the same repository, same deployment, same auth assumptions. If you hire me to build you a dashboard, I am extending patterns that already survived me being tired at 11pm before a launch — not guessing what operators want from a whiteboard.
Auth flows through PocketBase: the browser obtains a token via /api/site-auth, then reads and writes through /api/cms/* with that bearer token. Nginx proxies those paths to Node; Node talks to PocketBase on localhost. Admin never opens the PocketBase admin UI on a public port. The attack surface stays small.
The console is organized into five sections:
\n\nDashboard — Overview shows net traffic, unread lead signals, and ledger totals at a glance. One click publishes sitemap.xml from published PocketBase posts with canonical https://briancrabtree.me/ URLs. Sign-in methods (Google, GitHub OAuth) are managed here without a separate settings app.
Site — This is where most day-to-day content work happens. Blog is a master-detail journal editor: draft or publish, slug, summary, HTML body, header image URL, featured flag, and optional AI assist for expansion or title polish — not a chat widget on the homepage, just operator tooling where it saves time. Projects carries portfolio metadata plus the case-study band fields clients actually read on /projects/. Media uploads to PocketBase file storage. Site content edits hero copy, footer links, and related keyed sections. Announcement toggles the top bar. Testimonials and FAQ maintain the trust and contact-supporting copy without redeploying the SPA.
CRM — Leads aggregates form submissions with hunter and prospect tooling for outbound research. Inbox is the contact message queue with read state and reply flow. Newsletter manages subscribers and campaign broadcast records.
\n\nOps — Ledger tracks client invoices (including Stripe-imported paid rows linked to portal users). Calendar syncs Google Calendar availability and client meetings into PocketBase. Kanban boards attach to projects for delivery tracking. Notes is internal scratch space that does not belong on the public site.
\n\nSystem — Users controls roles and approval for client portal access. Audit log records destructive actions (invoice delete, project save, sitemap publish) with admin email and timestamp. Flags flips maintenance mode, heavy canvas toggles, and hero availability messaging. Gemini Live is an optional voice assist panel for operators who want it — isolated from the public bundle.
\n\nLayout follows a master-detail pattern: list on the left, editor on the right on desktop; on mobile, a step UI with command-bar section pills and a single scroll container so long project or journal lists are usable on a phone. Panel actions (Refresh, Save, Publish) surface in the command bar so you are not hunting for buttons below the fold.
\n\nOperator discipline matters. Before bulk PocketBase writes or scripted migrations, I run health gates (npm run verify:site-pb-health, npm run audit:site-pb) so empty shell records never pollute the public API again. Scripts that touch posts, projects, or testimonials call a write guard that blocks runs when collections are corrupted. That is the kind of fail-safe you want when agents and humans share the same production database.
Production deploys run through ./deploy.sh prod. The script builds the SPA, refreshes per-route shells, syncs dist/ to the webroot without deleting unrelated microsites, prunes old hashed assets after a window, regenerates the sitemap from published PocketBase posts, and runs an image URL verification pass. It is unglamorous. That is the point.
Nginx serves static files and proxies API traffic to Node on localhost. SSL and the edge cache sit in front on Cloudflare. Static assets get long cache lifetimes with hashed filenames; HTML stays fresh. For the full story on why a misconfigured Set-Cookie header can defeat your edge cache on JavaScript, see Why Cloudflare Refuses to Cache Your JS — I keep that detail in its own post so this one stays focused on stack shape.
When I hand a client a site, they get the same categories of artifact: repository access, deploy notes, analytics hooks, and a clear list of what was measured on the live URL. The reference build is the template for that handoff.
\n\nYou do not need to take my word for any of this. Open DevTools on the home page and watch the document request and the lazy chunks — you should see /api/public/* calls, not a database SDK initializing on first paint. View source on a journal route and confirm the shell metadata and prerender body. Read the “Verify before you hire” section and run your own Lighthouse pass on briancrabtree.me. Submit the contact form on mobile and confirm the layout does not collapse.
If you have credentials, /admin is where the operator console lives — same stack, same PocketBase collections, same deploy. Without credentials, the public API responses and this article are enough to see how data flows.
For the performance checklist I run before I call a handoff done, see Performance Checks Before Handoff. For lab versus field variance on PSI, start with Why PageSpeed Scores Change Every Run.
","tags":["react","pocketbase","vite","admin-dashboard","performance"],"views":72}