peopleanalyst

Parts · all properties

The shapes that hardened across products.

Two grains of reuse. Capabilities are application-level functional building blocks — survey delivery, data warehousing, profile pages, Monte Carlo engines. Each one is something a PM would put on a feature list. Patterns are the engineering techniques underneath — domain-agnostic code shapes that compose into capabilities. A capability is usually an assembly of several patterns.

↓ Capabilities·↓ Patterns

Capabilities

Application-level building blocks.

When standing up a new app in this portfolio, the first question is what's already here that I can reuse whole? These are the answers — survey respondent interfaces, profile pages, segmentation engines, statistical analysis. Each lives in an origin repo and shows up wherever else it's been needed. Capabilities can stay domain-aware (unlike patterns); the data shape and surface shape are what transfers.

Recurring across products

3+ repos · highest leverage

Strong single-origin

1–2 repos · clearly extractable

Patterns

Engineering techniques.

Code-level shapes — domain-agnostic, copy-paste-ready. Each repo carries a REUSABLE_PATTERNS.md of production-validated techniques stripped of business context. The most interesting signal is the overlap: where the same shape was independently arrived at across two or three codebases. That is where architectural conviction lives.

Cross-product convictions

Patterns named in 2+ repos

  • Three-tier database client split

    • vela #1 (Three-Tier Supabase Client Split)
    • namesake #1 (Three-client database factory)

    One DB serves browser, SSR, and trusted scripts — three different credential lifetimes. A single client either over-shares (service-role key reaches public routes) or under-serves (admin operations fail RLS). Both repos that have this surface independently arrived at the same factory split.

  • Idempotent upsert on a composite natural key

    • vela #9 (Idempotent Pipeline Upsert by Natural Key)
    • namesake #2 (Idempotent upsert with composite conflict key)

    Any pipeline write that may be retried — webhook redelivery, double-submit, mobile reconnect, ingest re-runs after a script crash — needs a unique key the database enforces, not the application. Both repos pin this as the safe-re-ingestion primitive.

  • State machine via DB columns + action endpoints

    • vela #8 (Editorial Lifecycle State Machine)
    • devplane P04 (Discriminated-Union State Machine with Two-Phase Commit)
    • namesake #13 (State-machine via DB columns + action endpoint)
    • performix #9 (Action-status transition gate — lightweight state machine)

    Editorial / curator / lifecycle workflows do not justify a dedicated state-machine library. A status enum + sticky transitions + per-action endpoint covers most cases without the orchestration tax.

  • Three-way adapter factory (mock / HTTP / MCP) with env switch

    • performix #2 (Three-way adapter factory with env switch)
    • devplane P09 (Runtime Provider Registry)

    Capabilities that need a back-end implementation parameterized by environment — tests want a mock, dev wants a local HTTP service, production wants the MCP gateway — converge on the same shape: one port, three adapters, an env-driven factory cached per process. The caller never sees the switch.

  • Tier-gated read path with server-only boundary

    • performix #5 (Tier-gated read path with `server-only` boundary)
    • devplane P13 (Server-Rendered Page with Injected Initial State)
    • vela `lib/platform/` no-outside-imports kernel boundary

    Multi-tier storage where lower tiers carry sensitive data converges on a single `server-only`-marked read module per tier. Build-time crash if a client component imports it. Belt-and-suspenders over RLS — the tier discipline prevents the import, the auth layer prevents the access.

  • Long-running compute on a separate worker

    • vela #2 (Async GPU Job via Webhook-Triggered Spawn)
    • namesake #19 (Long-running compute on a separate worker)

    GPU training, dataset ingest, large LLM batches — anything that outlives a request — needs a worker process, not a serverless function. Both repos formalize the pattern with a status table the frontend polls instead of a webhook the worker fires.

  • Validator at the boundary; trust-the-core within

    • devplane P05 (Validator-at-the-Boundary for Untrusted Input)
    • vela #27 (NULL-Safe `.neq` in Postgres Query Builders)
    • performix #8 (Zod-validated request/response envelope)

    Untrusted input — webhooks, browser POSTs, third-party APIs — gets validated once at the perimeter and turned into a typed structure the rest of the system can rely on. The internal layers stop re-validating; they accept the typed input and crash loudly if it is wrong.

  • Public-route allowlist inside an auth-first middleware

    • devplane P15 (Public-Route Allowlist in an Auth-First Middleware)
    • vela #24 (Public-Twin Design Reference Route)

    Protect-everything middleware with a small regex allowlist for the few public endpoints. Easier to reason about than the inverse: public-by-default with an explicit list of protected routes.

  • Cron tick + DB checkpoint over detached processes

    • vela #31 (Cron Tick + DB Checkpoint)
    • devplane P03 (Pull-Mode Event Source via Log Polling)

    Long-running jobs — ingest pipelines, training queues, recurring sweeps — survive restarts and deploys when their state lives in a status column on the work table, not in `nohup` or `/tmp`. The cron just ticks; the work table remembers.

Per-product pattern catalogs

8 of 8 live · rest forthcoming

DevPlane

23 patterns

A multi-agent coordination cockpit. Heavy on file-backed state, signed webhooks, two-phase actor handoffs, and runtime provider registries that plug concrete services into a generic flow engine.

→ full pattern catalog

source: people-analyst/devplane

Namesake

20 patterns

An intentional baby-naming platform. Heavy on dense entity pages, weighted-score blending with null-safety, and personalization re-mapping when user preferences are captured at finer granularity than the underlying score components.

→ full pattern catalog

source: people-analyst/baby-namer

Principia

14 patterns

A source-graded registry of organizational science exposed over a versioned REST + MCP contract. Pattern catalog is scaffolded upstream and will populate as the engagement-family ingest pipeline matures.

→ full pattern catalog

source: people-analyst/principia

Performix

18 patterns

Protected-feedback performance intelligence with a precompute-and-playback architecture. Eighteen patterns total: the load-bearing shapes (Insight player paradigm, the privacy gate, the three-way adapter factory, MCP consumer discipline, the binding-constraint diagnostic), the cross-portfolio sharing shapes from the Wave 1–10 marketing-site build-out (packages-dir with vendor-pin, theme-agnostic exportable component with render-prop chart slot, sibling-repo build-time sync), and the substrate-pipeline scaffolding (NotImplementedError per stage, three-tier promotion gate with sticky rejection, watchlist-driven harvest, frontend-only sandbox of the production diagnostic).

→ full pattern catalog

source: people-analyst/performix

People Analytics Toolbox

20 patterns

Nineteen live, co-deployed analytical microservices behind one Next.js app, each with its own Postgres schema, typed Zod contract, and parallel HTTP + MCP transports. They compose in two tiers: low-level measurement and decision building blocks (PA Instruments) snap together into finished products like a Leadership Index and an analytics-plan generator. The patterns underneath document how one repo runs many services without drift: per-spoke contract versioning that flows into a central registry, the same algorithm reachable from browsers and AI agents, anonymity gates and tokenization as composable primitives, and a fire-and-forget audit discipline that never blocks the call.

→ full pattern catalog

source: people-analyst/people-analytics-toolbox

Fourth & Two

13 patterns

Four converging efforts on one fantasy-football substrate — GM workflow app, Python analytics service, composable Insight Cards, and a coaching-strategy simulation game. The first thirteen patterns extract the stable subsystems: the platform-adapter port, the layered domain-state model, the CAMS framework adaptation, the card-relevance engine, and the polyglot two-runtime architecture.

→ full pattern catalog

source: people-analyst/mfl-command-center

CanonicAI

14 patterns

A two-repo content-ingestion engine: a heavy local pipeline (collector, organizer, quality gate, classifier) emits durable canonical-output artifacts per source; a thin cloud API host serves them over REST + MCP. Patterns extract the load-bearing seams — the pipeline-vs-host split, the checkpoint-resumable staged pipeline, the SHA-256 mirror with restore-verify, multi-source reconciliation with quality-flag gates, and the vendored consumer-contract pattern with explicit semver ratification.

→ full pattern catalog

source: people-analyst/meta-factory + people-analyst/meta-factory-prod

Vela

39 patterns

An adaptive figurative-art platform. Heavy on Postgres ergonomics, Supabase tier discipline, async GPU work, and editorial-state machines that survive automated re-runs.

→ full pattern catalog

source: people-analyst/vela