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)

    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.

  • 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)

    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

Full repo pattern documents

Vela

31 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

DevPlane

20 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