Building My Own Dashboard, Part 1: Why I Built It Instead of Buying One

The product serves as a living case study. I run Forty4, where I build AI-native products and validate the approach by running my own. The system includes a dashboard, an AI assistant with real write access to my CRM, a research bot that proposes content, and a coding agent running on a droplet. Much of the implementation was driven by AI.

Notion, Linear, and HubSpot didn’t fit what I needed. Each one pushed me into someone else’s workflow. I wanted a system that fits how I work, not how a vendor thinks I should work.

A Reference Implementation

Before I wrote a line of code, I studied a reference implementation that had already solved this problem: Baseline HQ, built by Trent Mitchell. His system proved that the architecture, the dashboard, the AI assistant, the research bot, and the coding agent were all viable on a droplet. I didn’t copy it. I learned from it.

Content First, Database Second

On day one, I had a spreadsheet with eight tabs: Calendar, CRM, Interview Backlog, Experiments, Podcasts, Metrics, Partners, Rules. The CRM tabs were markdown tables I edited by hand. The calendar was a markdown table. The interview backlog was a markdown table.

I made a simple rule: the knowledge base lives as real Markdown files in git. Not a CMS. Not a database. Files I can read, version, search, and, eventually, have an AI agent read and write through the GitHub API.

This wasn’t philosophical. It was practical. When something is just text in a repo, you move fast. You don’t need a database until you actually feel the limits.

That rule, content first, database second, is the single decision that made everything else possible. It let me build the marketing pipeline, the CRM, the interview loop, and the AI assistant on a foundation that never fought me.

How the System Works

Four pieces, each with one job.

The Dashboard is the web app I use every day, built on Next.js and React. It handles the marketing calendar, the CRM, interviews, analytics, and AI chat.

The CLI is a terminal command (forty4 status, forty4 search, forty4 reindex) that shares the exact same logic as the dashboard. I can check deployment health or search the knowledge base without opening a browser.

The Core is the shared brain: database queries, content parsing, GitHub integration, LinkedIn posting, Vercel deployment, and chat storage. It has no build step, and the dashboard and CLI both import it directly.

The Content is the markdown knowledge base: my Experience Library (the stories and frameworks I’ve lived), the marketing playbook, and every approved implementation plan. Real files, version controlled, searchable.

Why Postgres Came Later

Postgres arrived in four phases, each triggered by real pain:

1. The CRM broke first. Markdown tables edited by re-fetching a file, patching text, and committing back don’t scale past a handful of records. No real queries. No joins. No filtering.
2. Search got slow. Reading the knowledge base off disk at request time doesn’t work as a search backend. A GitHub webhook on every push now keeps a Postgres index in sync. Rebuildable from scratch with one command.
3. The calendar drifted. Editorial calendar metadata lived in markdown. Draft content lived in Redis. Two systems that could drift became one that can’t.
4. Documents were exposed. CRM files sat behind public URLs. Moved to private storage with a dedicated download route as the only read path.

That last one wasn’t the only security gap I ran into along the way. There’s another, specific to how the AI assistant could read data, that I’ll get into next time.

Every migration kept the same function names (getContacts, createContact, searchCRM) so the API routes, the CLI, and the AI tools barely changed, just added await where they used to be synchronous.

Why Two Read Paths for the Same Content

This confuses people: the AI assistant reads and writes live against GitHub. The dashboard reads through Postgres.

Why? The assistant needs to see its own edit on the very next tool call. It can’t wait on webhook latency. The dashboard needs fast, ranked search without hitting GitHub’s API on every request.

How Authentication Works

Production uses Google sign-in restricted to an explicit allowlist. Previews fall back to HTTP Basic Auth (Google’s OAuth can’t wildcard to preview URLs).

The proxy layer’s cookie check is optimistic, presence only. The real check happens in every server component, action, and route that touches data. A forgeable cookie is not the security boundary.

What This Foundation Enabled

Everything that followed sits on this:

• A CRM that grew from markdown tables into a real relational system with private document storage
• A marketing pipeline that writes, checks, and schedules its own posts
• An interview loop that automatically builds the knowledge base powering all content
• An AI assistant that acts on the CRM, marketing, interviews, and research, not just chats
• observability that makes free-tier infrastructure actually sleep
• A personal Claude platform on a droplet with zero public ports

The content-first philosophy meant I could move fast on day one. The database-second discipline meant I only paid complexity costs when the problem was real. That’s the whole point: the product is a living case study, and this foundation is what lets it keep proving itself.

---

Next in this series: The Database Migration. Moving from markdown tables to Postgres without rewriting callers taught me to let pain drive architecture. It also includes the security gap that made every new table readable by the AI until a migration fixed it.

If you’re building an AI-native product and want a foundation that proves itself the same way, Forty4 helps teams ship systems like this from day one.