Things I've built.

Why this stack

Electron and TypeScript keep the Windows observer, state machine and always-on-top interface in one typed runtime. SQLite FTS5 makes memory local, inspectable and cheap to query. Codex CLI is a deliberately narrow reasoning gateway: calls are ephemeral, schema-constrained, read-only and only happen after deterministic policy finds enough evidence to justify one.

What I decided not to build

Kovacs provides advice without computer control. A deterministic gate decides when context warrants a model call; unchanged or insufficient evidence produces no intervention. This keeps routine observation separate from model usage and user actions.

Operational purpose

The product problem is guidance that either interrupts constantly or arrives without enough context to be useful. Kovacs makes silence the default, so screen sampling does not imply model spend and sensitive context stays local unless a guarded path explicitly allows more. The current release evidence is repository-scoped—not a production claim—and the ongoing pilot is designed to measure usefulness, false interventions, latency and privacy in real work.

Why this stack

Next.js provides the intake and staff interfaces; Supabase provides authentication, persistence and row-level policies alongside application authorization checks. Zod validates intake contracts. A constrained OpenAI call structures the input, while deterministic rules handle escalation.

What I decided not to build

I kept the intake workflow to one constrained model call, with escalation rules implemented separately in deterministic code. This limits orchestration complexity and lets the escalation logic be tested independently of model output.

Operational purpose

Medbay organizes conversational intake into a reviewable case for staff. Rule-based escalation does not require a model call. The single-call intake design limits orchestration overhead; actual API cost still depends on input and output tokens.

Why this stack

Python and FastAPI because the quantitative engines are the actual product, and numerical work lives in Python's ecosystem. PostgreSQL persists the frozen, hash-verified snapshots every analysis runs against; Redis caches the expensive computations. The React front stays deliberately thin — the value is in the engines, not the interface.

What I decided not to build

Numerical results come from deterministic engines, with optional model narration checked against stored artifacts. Frozen snapshots make a run inspectable and replayable, while the no-LLM path keeps the computed results available without narration.

Operational purpose

AtlasOS links reports to frozen inputs and engine artifacts so reviewers can inspect how figures were produced. Citation validation and evaluation fixtures check numerical claims. The computation path can run without LLM usage; this is research tooling, not evidence of live trading performance.

Why this stack

BullMQ on Redis because retention is fundamentally a queue problem: reminders and recovery flows are scheduled jobs that must survive restarts and stay inspectable when something goes wrong. Drizzle gives typed schemas where tenant scoping is enforced at the repository layer instead of per-route discipline, and Next.js carries the operations cockpit.

What I decided not to build

I prioritized scheduled workflows, deterministic engagement signals and retry visibility before adding churn prediction. That made job state and recovery behavior the first implementation concerns.

Operational purpose

CareLoop makes reminder and follow-up state inspectable. Deterministic job IDs and idempotent processing reduce duplicate work during retries; tenant-scoped repositories enforce access boundaries, and minimized payloads reduce sensitive data in queues. These mechanisms do not by themselves guarantee exactly-once external delivery or establish production security.

Why this stack

TypeScript lets the simulation and interface share domain types within one application. Keeping Monte Carlo computation in the same runtime avoids a separate Python service. The AI layer explains engine results rather than calculating the forecast.

What I decided not to build

The model never produces the forecast — AI reads the simulation, it does not write it. I also cut CRM integrations from v1 in favor of CSV import: the forecast math had to earn trust against known data before touching anyone's live pipeline, and every integration is a maintenance liability you carry forever.

Operational purpose

Konstellation exposes forecast ranges, assumptions and deal-level drivers for review. AI recommendations reference the computed factors. The project demonstrates an inspectable forecasting workflow; predictive accuracy depends on the assumptions and input data.

Why this stack

A local-first Node.js CLI with no server component, because guardrails have to run where the diff exists: adding a hosted service would mean shipping private code to a third party and paying infrastructure cost for something git already knows. The verifier is deterministic TypeScript over git diffs rather than another model, so policy checks are reproducible and versionable alongside the repo.

What I decided not to build

Deterministic checks fit rules such as allowed paths, secret patterns and test-change requirements. Versioned policy and Markdown/JSON audit output make each verdict inspectable without a model call. These checks complement code review; they do not establish that a change is correct or secure.

Operational purpose

The business problem is agent drift: plausible diffs that quietly expand scope, touch sensitive paths or skip tests, discovered only in code review or production. Fencier makes drift visible before a change lands. Each verification is a local git operation — zero API cost, no network round-trip — so teams can run it on every agent iteration instead of rationing checks.

Why this stack

NextAuth, Drizzle and PostgreSQL because in a multi-tenant care product the auth boundary is the product risk: sessions are tenant-scoped, tenant context is resolved from the host before any route runs, and ownership checks live next to the queries they protect. Zod validates every API boundary, because patient-facing input is untrusted by definition.

What I decided not to build

The first version focuses on intake, scheduling, ownership checks and audit events. Keeping it to a responsive web application reduced the number of clients to maintain while establishing the shared workflow.

Operational purpose

Vela brings intake, scheduling and patient records into one workspace. Host-resolved tenant context, scoped sessions and ownership checks enforce access boundaries. The project demonstrates those controls without claiming an independently audited security guarantee.

Why this stack

Python because the deliverable is the simulation, not an app: regime modeling and Monte Carlo work sit naturally on its numerical ecosystem, and Dash provides an analysis surface without building a frontend project around it. Results export as JSON and CSV because investment committees live in documents and models, not in someone else's dashboard.

What I decided not to build

The simulation uses explicit assumptions and numerical models without an LLM in the calculation path. Distribution outputs expose uncertainty across scenarios rather than presenting a single valuation as the result.

Operational purpose

The business problem is base-case valuations that hide how fast a macro regime change destroys them. Impairment probabilities with explicit, tweakable assumptions give allocators a defensible number to put in a committee memo — and the governance artifacts mean the analysis survives outside the tool that produced it.

Why this stack

A Node.js CLI keeps import, deduplication and scoring local. CSV outputs can be inspected in a spreadsheet. Optional Codex-assisted review requires explicit approval and may send the selected context to the model provider; the default scoring path does not require it.

What I decided not to build

CareerOS prepares and ranks opportunities while leaving submission to the user. Deterministic scoring runs before optional AI review so the ranking can be inspected separately from generated advice.

Operational purpose

CareerOS consolidates noisy listings into ranked decision tables and skill-gap reports. These artifacts help a user decide where to spend application effort; they do not infer why an employer rejected an application.