Meridian

Internal Project — our own product build

Chamber I · Opening

CareerKit

A standalone Python library carved out of a larger internal platform — extracted live, test-gated at every step, without breaking the system it came from.

Chamber II · The problem

The engineering story

A capability that had grown inside a larger internal platform needed to stand on its own — without breaking the platform that still depended on it, and without a risky big-bang rewrite.

Chamber III · The method

How it was built

The extraction ran as a strangler-fig migration: the new library grew alongside the old code path, absorbed responsibility piece by piece, and the old path was retired only when the test suites proved parity. The production data migration follows the same discipline — its tooling is built and dry-runnable, and the live table move is scheduled behind a database-backup gate.

  • Standalone Python library, standard library only — zero third-party dependencies to install, audit, or break.
  • Hexagonal design with injectable seams: all I/O sits behind interfaces that can be swapped in tests, so the core logic is verified in isolation.
  • Test-gated throughout: 154/154 tests passing (re-verified 2026-07-12) — every extraction step had to keep the whole suite green before it landed.
  • Data-migration tooling built and dry-runnable; the live table migration is deliberately gated behind a database backup — it runs when the backup gate clears, not before.

Chamber IV · The evidence

Craft evidence

A real artifact from the build.

Chamber V · Future vision

Where this is heading.

Future Vision · Concept Today CareerKit is a local, single-user command-line library — the extracted engine and nothing more. The direction we are designing toward is a product others could run: a multi-user tool built on the same test-gated core, where the discipline that proved the extraction would prove every feature shipped on top of it. That is a concept of where this could go, not a shipped product; it carries no users, no revenue, and no outcomes, because there are none to claim yet.

Chamber VI · The foundation

What's measured next

This entry is an engineering case study: what it claims is exactly what the test suites prove. Product-level results will be reported from the products the library ships inside — when they're measured, not before.

Verified, not claimed

  • 154 / 154 tests passing — re-verified 2026-07-12; every extraction step had to keep the whole suite green before it landed.
  • Zero third-party dependencies — a standalone Python library, standard library only: nothing to install, audit, or break.
  • Hexagonal design, injectable seams — all I/O sits behind interfaces swapped in tests, so the core logic is verified in isolation.
  • Migration tooling built and dry-runnable — the live table move stays gated behind a database backup, run only when the gate clears.

Have a system that's grown past its container?

This build maps to our Systems cluster — the same migration discipline applies to untangling any business-critical codebase without downtime. If a business-critical system has grown past its container, the AI Opportunity Diagnostic will show where it costs you hours and enquiries — and what to untangle first, with us or without us.

Book the Diagnostic → All work →