Portfolio Command Center for Consulting

Background

Running a portfolio of 14+ web properties — each with its own audience, content, financials, and SEO posture — surfaces an obvious-in-retrospect operations problem: the per-site tools don't compose. Google Search Console gives you per-site index coverage but not a portfolio view. Lunch Money or QuickBooks tells you about cash flow but not how it ladders to per-project revenue. Your secrets manager knows what's deployed but not whether the content pipeline is healthy. Every operational question becomes "log into five tools and reconcile manually."

The Autonomous AJ Command Center (AACC, live at cc.autonomousaj.com) is the platform we built to solve this for our own operations. It started as a place to watch portfolio health and grew into the orchestration layer for content pipelines, financial dashboards, GSC monitoring, and project tracking across every site in the portfolio.

The problem

Specifically, we needed:

• One canonical model of "what projects exist" — slugs, domains, schemas, deploy targets, business state — that other tools could read instead of duplicating.
• Continuous health audits per project: can we reach the database? Are the expected tables and columns there? Is content actually publishing? Are recent posts indexed?
• The programmatic SEO pipeline (covered in a separate case study) needed somewhere to live, with read access to per-project credentials so it could publish to remote project DBs.
• A financial layer that pulls from the systems where money actually flows — Lunch Money for transactions, the project database for revenue attribution — and produces dashboards we'd actually look at.
• A central place to run scheduled work — content generation, GSC sync, health audits — without spreading cron tabs across 14 servers.

The approach: a Django + FastAPI + React platform with project tracking at the core

The TrackedProject model

Every web property in the portfolio is a row in TrackedProject: slug, name, production URL, Doppler project name (defaults to pa-<slug>), content readiness configuration. This is the canonical model that everything else hangs off of. When AACC needs to talk to a destination database, it resolves credentials via doppler run --project pa-<slug> --config <env>; when a service needs to know what schema to use, it reads from per-project config first, falling back to a hard-coded mapping.

Continuous content readiness audits

A ContentReadinessService audits every active project in dev and prd, checking: Doppler returns a DATABASE_URL, the connection opens within 10s, the configured schema exists, the content tables and required columns are present, post counts and last-post dates look healthy, and dev/prd parity is within tolerance. The output is a structured readiness report that surfaces drift before it becomes a deploy outage.

Programmatic SEO pipeline

The seed → generate → link → hub → quality → publish flow for the portfolio's programmatic SEO content runs as management commands inside AACC. Pages generate against AACC's own tables, then publish UPSERTs the result into each destination project's programmatic_page table over a Doppler-injected connection. The whole pipeline is multi-tenant by design: adding a new destination is a TrackedProject row plus a Doppler config, no code changes. The first portfolio site through the full pipeline (this site) shipped 1,855 pages.

Financial dashboards

A Lunch Money API integration pulls transactions and rolls them up into cash flow projections, debt management, net-worth tracking, and tax estimates. Per-project revenue gets attributed where the project's data exposes it. The dashboards are the same React components the rest of AACC uses — daily scorecards, trends, drill-downs — running over Django models that wrap the Lunch Money API responses.

GSC + content operations

GSC integration syncs index coverage, sitemap status, and top pages per site. ContentGeneration manages the AI brief → draft → quality gate → publish flow for non-programmatic content (blog posts, newsletters). Both run on Celery Beat schedules so the operational rhythm is automatic rather than manual.

Stack-internal architecture

The platform itself is Django 5.2 (models, admin, scheduled work) + FastAPI (thin API gateway for the React frontend) + React + TypeScript (operational dashboards). Postgres is on Supabase (multi-schema for projects on Supabase; direct connection per-project for projects on dedicated Postgres like Purcell Analytics). Celery + Celery Beat handle scheduled jobs; Doppler injects secrets at runtime; Anthropic and OpenAI SDKs power the content-generation side. The codebase is mid-size — large enough to have its own architecture patterns, small enough that one operator maintains it.

Outcomes

A few concrete things that are true:

• Portfolio-wide operations run from one place. Adding a new site is a TrackedProject row + a Doppler config + a destination DB; AACC's tools (audits, content pipeline, financials) automatically include the new site.
• Content publishing is centralized and auditable. The 1,855 programmatic pages on this site, plus the day-to-day blog publishing, all flow through AACC.
• Health checks happen continuously rather than at deploy time. Drift between dev and prd schemas, missing tables, expired credentials all surface before they become Saturday-morning emergencies.
• Financial visibility is real-time rather than monthly. The dashboard reflects the previous business day's transactions, not a spreadsheet last touched in March.

We don't publish portfolio-level revenue or cost numbers — they're not relevant outside the practice. The operational outcome that matters is the one we can describe: AACC is the system we look at first thing in the morning, every morning.

The stack

Django 5.2 + DRF, FastAPI gateway, React + TypeScript dashboard, Postgres (Supabase + per-project), Celery + Celery Beat for scheduled work, Doppler for multi-project secret resolution, Anthropic + OpenAI SDKs for content-generation features, Lunch Money API for financial integration, GSC API for indexation tracking, and a custom set of management commands that orchestrate the cross-project flows.

Most of what AACC does is stuff every consulting practice eventually wants but rarely gets around to building. If you're running multiple revenue sources or projects and finding that your operations are spread across five SaaS tools — that's exactly the kind of consolidation we do.