The Capstone: basecamp + Abukix Studio

The 60-month integrated build. Ten OSS projects compose into one platform — basecamp — that mirrors frontier-lab platform patterns at homelab scale. Abukix Studio is its visible product surface. Five thematic years; one coherent artifact at the end.

5 years. 9 OSS projects. One platform. The capstone is not something you build at the end — it’s the single coherent system you’ve been building all along, one tier at a time.

The bet of the program is that most engineers ship disconnected tools because that’s how programs are scoped, and most portfolios suffer for it. A senior engineer’s portfolio sells because it shows judgment across a system, not skill across a list. The capstone is the structural answer to that: every phase ships a piece, every piece plugs into the same growing platform, and by end of Year 5 the platform stands on its own as a single end-to-end artifact.

This document is the spine that holds it together. Each phase doc tells you what to ship from that phase. This doc tells you what the whole is becoming, and where each piece sits in it.


Why end-to-end beats per-tool

A typical learning portfolio after five years of self-study looks like this:

github.com/you/regex-cli         (Python tutorial output)
github.com/you/k8s-todo-app      (followed a K8s course)
github.com/you/llm-chatbot       (chatGPT clone)
github.com/you/feature-store     (some Medium article)
github.com/you/ml-pipeline-demo  (a capstone)
... 12 more repos ...

Each repo is a credible tutorial-shaped artifact. None of them compose. An interviewer scrolling that profile sees motion, not direction.

The capstone fixes this by making every project a load-bearing component of one larger system. The repos don’t replace each other; they connect. By end of Year 5 a senior engineer reviewing your work doesn’t see fifteen tutorials — they see one platform built by an engineer who understands how the layers fit.

Disconnected portfolioIntegrated capstone
15 repos, each scoped to a tutorial9 repos, each a tier of one platform
”Built X with Y” demos”Composed X with Y to solve Z” systems
Reviewer’s question: can they go deep?Reviewer’s question: they already went deep — where?
Sells effortSells judgment
Junior-coded ceilingSenior-coded ceiling

The cost is real: a capstone requires upfront architectural coherence and stricter shipping discipline (“does this tool earn its keep in the platform, or am I just adding clutter?”). The payoff is that the whole becomes more than the sum of the parts — which is the only portfolio shape that actually distinguishes a senior IC from a credential-collector.


What the capstone is

basecamp is the platform. Abukix Studio is its visible product surface (Tier 9 — the UI + command palette + control plane). Together they’re the artifact the program builds.

basecamp is K8s-native end to end. Every component is a CRD-driven controller composing through the Kubernetes API. Patterns first is /root’s bet; among tools-that-implement-the-pattern, K8s-native equivalents earn priority because they compose. See K8s-native ecosystem as meta-pattern for the philosophical anchor.

Both run on a single homelab mini-PC. Both are versioned in Git. Both are operated through GitOps (Flux) from Year 3 onward. Both mirror — at small scale — the patterns frontier-lab platforms operate at planetary scale.

The bet: if the patterns are right, scale is just a number. A homelab K3s cluster running a vector store, a feature store, an LLM gateway, AIOps agents, and a Studio UI on top, using the same control-loop / declarative / GitOps / data-fabric patterns as a hyperscale platform, is a real demonstration of pattern fluency. Scaling it up is staffing and budget. Pattern fluency is the thing that’s hard to fake.


The 9-tier basecamp

TierComponentOSS project(s)YearIndustry parallel
1 — FoundationK3s + Flux + CloudNativePG operator + Redis Operator + Karpenter + Keda + Prometheus + Grafana(basecamp GitOps repo)Y3Hyperscale K8s substrate + observability
2 — ReliabilityCilium mesh + Hubble + OTel Collector + Tempo + Loki + Pyrra SLOs + Kyverno policies + pulse + triagepulse, triageY1, Y3Hyperscale observability stacks
3 — IaC + CloudCrossplane XRDs (primary K8s-native IaC); Terraform as compare; multi-cloud (homelab + AWS + GCP)terralabsY3Crossplane XRDs at frontier-lab scale
4 — Platform Controlplatform-ctl (paved-road CLI) + custom kubebuilder operator + Workload / Tenant CRDs + service catalogplatform-ctl + platform operatorY3Internal paved-road platforms + CLI
5 — DataStrimzi (Kafka operator) + Iceberg + MinIO + Spark Operator + Airflow/Dagsterdata-tier (umbrella)Y4Iceberg-based lakehouse + unified catalog
6 — ML InfraKubeRay (Ray operator) + MLflow + KServe + Feast + pgvector/MilvusML infra helpersY4-Y5Ray clusters + feature store + embedding store
7 — LLM/AgentLangGraph + MCP + vLLM/llama.cpp + agent runtimellm-gateway, MCP serversY5Internal LLM gateway + agent platform
8 — AIOpsSelf-healing + agent triage + AIOps on ops-handbook corpusservices/aiops/Y5(frontier)
9 — Studio MVPWeb UI + command palette + composition recipes over Tiers 1-8Abukix Studio v0Y5Internal platform product UI

Two longitudinal artifacts run alongside the tiers and survive the whole program:

  • ops-handbook — runbooks, postmortems, ADRs, weekly logs. Built from Y1 Phase 1 onward. By end of Y5: ~250 weekly logs, ~25 postmortems, ~140 runbooks, ~15+ ADRs. Private repo; sanitized public extract considered around Y4.
  • basecamp repo — the GitOps source of truth declaring every tier above. Private at first; goes public during Year 3.

How the tiers compose

Tiers stack. Each one runs on the tiers below it, and operates the tiers above through interfaces.

                ┌─────────────────────────────────────────────────┐
   Tier 9       │   Abukix Studio (Web UI + command palette)      │
                └─────────────────────────────────────────────────┘

                ┌─────────────────────────────────────────────────┐
   Tier 8       │   AIOps: agents operating the platform          │
                └─────────────────────────────────────────────────┘

                ┌─────────────────────────────────────────────────┐
   Tier 7       │   LLM gateway + Agent runtime + MCP             │
                └─────────────────────────────────────────────────┘

                ┌─────────────────────────────────────────────────┐
   Tier 6       │   ML Infra: Ray + MLflow + KServe + Feature     │
                └─────────────────────────────────────────────────┘

                ┌─────────────────────────────────────────────────┐
   Tier 5       │   Data: Iceberg + Kafka + Spark                 │
                └─────────────────────────────────────────────────┘

                ┌─────────────────────────────────────────────────┐
   Tier 4       │   platform-ctl: service catalog + deploy CLI    │
                └─────────────────────────────────────────────────┘

                ┌─────────────────────────────────────────────────┐
   Tier 3       │   terralabs: Terraform/Crossplane (IaC)         │
                └─────────────────────────────────────────────────┘

                ┌─────────────────────────────────────────────────┐
   Tier 2       │   pulse + triage: observability + reliability   │
                └─────────────────────────────────────────────────┘

                ┌─────────────────────────────────────────────────┐
   Tier 1       │   K3s + ArgoCD + Postgres + Redis + Prom + Graf │
                └─────────────────────────────────────────────────┘

                ┌─────────────────────────────────────────────────┐
   Foundation   │   Linux host (Proxmox) + homelab hardware       │
                └─────────────────────────────────────────────────┘

   Side rail:   ops-handbook  (runbooks, postmortems, ADRs, weekly logs)
                basecamp repo (GitOps source of truth)

The composition rule is strict: a tier cannot ship until the tier below it is operational. You don’t get to ship llm-gateway (Tier 7) before MLflow + KServe (Tier 6) is live, and you don’t get to ship those before Postgres + Prometheus (Tier 1) are humming. That’s not bureaucracy — it’s how the platform stays debuggable. When Tier 7 misbehaves in Year 5, you can trust that Tier 1 is solid because you’ve been operating it for two years.


Year-by-year build progression

Year 1 (Software Engineering Foundations): no platform tier yet

No basecamp tier this year — just the foundations every later tier rests on. You ship two fluency CLIs (rxp, pulse) and start the ops-handbook discipline. The platform doesn’t come alive until Year 3, but the engineer who will operate it gets built here.

Year 2 (Backend Engineering): still no platform tier

Year 2 ships backend services running locally in Docker. You can ship a real API end-to-end with auth, databases, tests, CI/CD. No basecamp tier yet — that arrives in Year 3 when Kubernetes lands.

Year 3 (Infrastructure & Platform Engineering): Tiers 1-4 alive

By end of Year 3:

  • K3s running on the mini-PC; ArgoCD bootstrapped via GitOps
  • Postgres + Redis deployed as StatefulSets, with backups configured
  • Prometheus + Grafana scraping pulse, services, node metrics
  • triage deployed as the first real service-on-platform via ArgoCD (Tier 2 reliability)
  • terralabs declaring the homelab + AWS + GCP via Terraform/Crossplane (Tier 3, first loud OSS launch)
  • platform-ctl as the paved-road CLI + service catalog (Tier 4)
  • basecamp repo goes public mid-Y3
  • Service mesh (Cilium) + secrets lifecycle + SLO discipline + FinOps + reliability engineering all operational

What basecamp can do at end-of-Y3: run small services declaratively across multi-cloud, observe them, alert on them, store their state durably, recover from individual failures, enforce zero-trust between them, track cost. It is a recognizable mini-platform — the kind a small startup would actually run.

Year 4 (Data Engineering & ML Foundations): Tiers 5-6 alive

By end of Year 4:

  • data-tier components: MinIO + Iceberg + Nessie/Polaris (Tier 5)
  • Kafka cluster + Debezium CDC + Kafka Streams / Flink for streaming
  • Spark mini-cluster + Airflow/Dagster for batch + orchestration
  • Ray cluster + MLflow tracking + KServe serving (Tier 6 entry)
  • First model trained-registered-served end-to-end through the new infra
  • Postgres + Iceberg integrated via CDC; the data tier serves both OLTP and OLAP

What basecamp can do at end-of-Y4: ingest events at high rate, store them durably in object storage with table semantics, run analytical queries, run batch and streaming pipelines, train models on Ray, serve inference through KServe. It is now a recognizable mini-data-platform with ML capability — small startup territory.

Year 5 (AI Infrastructure): Tiers 7-9 alive, capstone

By end of Year 5:

  • Feature store (Feast) operational with train/serve parity verified
  • Vector store (pgvector or Milvus) + embedding pipelines + RAG endpoints
  • LLM serving (vLLM) on the local GPU; inference optimization (quantization, speculative decoding) applied
  • Fine-tuning workflows (LoRA, QLoRA, PEFT) running
  • llm-gateway shipped publicly (Tier 7 entry): routing, caching, observability, fallback, evals
  • MCP servers + agent runtime + AI security + AI observability operational (Tier 7 completes)
  • services/aiops/ — Tier 8 alive: agents triage incidents, propose runbooks, execute through platform-ctl (approval-gated)
  • Abukix Studio MVP — Tier 9 launched publicly
  • Pattern paper published — the synthesis writing artifact

What basecamp can do at end-of-Y5: the full multi-tier AI platform. Trains models, serves them, routes LLM traffic through a gateway with observability and fallback, runs agents that operate the platform autonomously (with human approval gates on destructive actions), and presents all of it through a clean Studio UI a stranger can land on. Smaller scale than frontier labs, same patterns.


What each OSS project is, briefly

Short blurbs. Each links to its full plan.

  • rxp (Y1 Python) — regex CLI. Fluency artifact, later reused as the log-pattern utility inside services/aiops/ (Y5).
  • pulse (Y1 Go) — probe scanner emitting Prometheus metrics. Fluency artifact, scraped by basecamp from Y3 onward.
  • triage (Y3) — on-call dashboard. The first real service on basecamp; reads alerts + recent incidents + ops-handbook for the on-call view.
  • terralabs (Y3) — IaC with Terraform + Crossplane, multi-cloud. First loud public launch of the program.
  • platform-ctl (Y3) — service catalog + deploy CLI. Paved-road templates for new services.
  • data-tier umbrella (Y4) — Iceberg helpers + Kafka utilities + Spark utility crates.
  • llm-gateway (Y5) — LLM routing layer with caching, observability, fallback, evals. The production-grade LLM-gateway pattern at small scale.
  • MCP servers + agent runtime (Y5) — mcp-ops-handbook, mcp-data-tier, mcp-platform-ctl + LangGraph runtime that uses them.
  • services/aiops/ (Y5) — agents that operate the platform: incident triage, runbook execution, pattern detection from postmortems.
  • Abukix Studio v0 (Y5 capstone) — Web UI + command palette + composition recipes. The visible product surface.

Each one earns its keep: it’s not a portfolio tile, it’s a load-bearing component that the next tier above relies on.


What the public site looks like at end of Year 5

The single artifact a reviewer opens. Layout:

public-site/
├── /                        ← landing: "Building an AI Platform in Public"
├── /program/                ← the 5-year curriculum (this site's program section)
├── /basecamp/               ← LIVE: the platform itself, embedded
│     ├── Tier 1-9 status   ← (live K8s state, rendered by Studio)
│     ├── Service map       ← what's running, what depends on what
│     ├── Agent activity    ← AIOps + agent runtime traces
│     └── Recent activity   ← last 30 days of deploys, alerts, incidents
├── /patterns/               ← Pattern Library: ~70 patterns, ~50+ DEEP
├── /projects/               ← 9 OSS project plans, READMEs, repo links
├── /blog/                   ← ~250 posts (Sunday weekly logs distilled)
│     └── /pattern-paper/    ← the synthesis essay (Year 5 capstone writing)
├── /talks/                  ← conference talks recorded (1-2 per year, 5+ total)
└── /capstone/               ← THIS DOC: the 60-month arc, where reviewers start

The interview pitch becomes one sentence:

“I spent 5 years building an AI platform from the kernel up, end-to-end and opensource — 9 tiers from K3s through an LLM gateway, AIOps agents, and a Studio UI on top. Same patterns as the platforms I’d be operating at scale. Here’s the URL. The blog explains the 60 months that got me here.”

That sentence is the difference between a credential-collector and a senior IC. The capstone is what makes it true.


Pattern depth across the capstone

By end of Year 5, ~50 of ~70 Pattern Library entries should be DEEP — meaning you’ve operated something dependent on the pattern for 3+ months. The capstone is the operating ground that forces the patterns to deepen.

Pattern categoryTier(s) that operate itDEEP target
Foundations (virtualization, privilege-separation, mediation, layering, control-loops)Tiers 1, 6, 7All 5 DEEP by Y3 end
Software architecture (DDD, clean, hexagonal, repository)Y1-Y2 servicesDEEP by Y2 end
Storage and data (WAL, LSM-vs-Btree, OLTP-vs-OLAP, replication)Tiers 1, 5All DEEP by Y4 end
Distributed systems (idempotency, replication, backpressure, fault-isolation, consensus)Tiers 1, 2, 6Most DEEP by Y3 end
Networking (routing, load-balancing, service-discovery, network-policy, mesh)Tiers 1, 2, 5All DEEP by Y3 end
Infrastructure-and-platform (declarative, GitOps, paved-road, service-catalog, FinOps, reliability)Tiers 1, 3, 4All DEEP by Y3 end
Data engineering (lakehouse, schema-evolution, streaming-vs-batch, CDC)Tier 5DEEP by Y4 end
ML systems (feature store, training/serving, evals, prompting, agent loops, fine-tuning, RAG)Tiers 6, 7Most DEEP by Y5 end
AI safety + observabilityTiers 7, 8DEEP by Y5 end

The Pattern Library by end of Y5 has ~70 entries with ~50 at DEEP — the program’s structural target.


Anti-patterns

Anti-patternWhy
Perfecting Tier 1 before moving to Tier 2Tier 1 will keep evolving as Tier 7 stresses it. Stop polishing; start composing.
Adding a new OSS project “for the portfolio” mid-programEvery new tool dilutes the capstone narrative. The 9 listed here are the 9.
Skipping ops-handbook discipline “until things stabilize”The handbook is the stabilization. Skip a month and the dataset for AIOps degrades forever.
Treating basecamp as separate from the OSS projectsThe OSS projects ARE basecamp. There’s no “and basecamp.” triage deployed-via-ArgoCD on K3s is basecamp.
Building Studio early “for the screenshots”Studio MVP is end-of-Y5 for a reason — it needs the underlying tiers to render anything meaningful. Premature Studio is a fake demo.
Cargo-culting hyperscale specificsMirror the patterns, not the org-specific implementation details. Your llm-gateway doesn’t need any specific hyperscale gateway’s API surface; it needs the same caching + routing + observability shape.

What to do next

If you’re starting Year 1: bookmark this doc and re-read it at the start of every phase. Each phase doc tells you what to ship; this doc tells you why and where it fits.

If you’re mid-program: read your current phase’s “What ships from this phase” section against the tier table above. The two should agree. If they drift, the phase doc is wrong (flag it) or your scope is creeping (cut it).

If you’re approaching Year 5: start writing the elevator pitch above as a 60-second video on the public site’s /talks/ page. The pitch is real prep, not vanity.


→ Back to: The Master Plan · Year 1