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

I refused to give Kovacs control of the computer. It cannot click, type, publish, commit or silently resume observation after restart. I also cut continuous model interpretation: unchanged, weak or unsafe context ends in silence, while local policy owns routine decisions. That makes the product less theatrical and substantially easier to trust.

Business impact

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 plus Supabase because a clinic-facing console needs auth, row-level security and persistence without a dedicated backend team — the security boundary lives in the database, not in application code I have to re-audit. Zod sits at every boundary because intake data is untrusted by definition. The AI layer is one constrained OpenAI call for structuring, not an agent framework: anything safety-critical must not depend on a model's mood.

What I decided not to build

I cut a multi-agent LangGraph pipeline early in the build. More agents meant more tokens, more tail latency and more surface to audit — and none of it made triage safer. The final shape is one model call per intake and zero model calls on the safety path: escalation rules are plain deterministic code that costs nothing and returns the same answer twice.

Business impact

The business problem is intake context dying in reception: conversational, incomplete information that staff re-collect by phone. Medbay turns it into a reviewable case with an explicit state. Because safety routing never touches the LLM, escalation decisions run in constant time at zero token cost, and API spend stays flat and predictable per case instead of scaling with conversation length.

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

The model is never allowed to produce a number. Narration is an optional layer on top of deterministic output, every claim is citation-validated against the source datum, and the whole platform degrades gracefully to no-LLM operation. I also rejected 'live' streaming analysis in favor of frozen snapshots: for research, reproducibility beats freshness.

Business impact

The business problem is analysis you cannot replay: if a thesis can't be traced back to its inputs, it can't be audited or trusted with capital. Every AtlasOS run is reproducible from its snapshot hash, uncited claims are caught by the eval suite before a human reads them, and the deterministic core costs zero tokens to operate.

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 skipped AI churn prediction entirely for v1. A model guessing who will churn is worthless if the reminder pipeline silently drops jobs — so the budget went into deterministic engagement signals, idempotent job IDs and retry visibility. Boring reliability first; prediction can be layered on once the plumbing has earned trust.

Business impact

The business problem is silent revenue leakage: patients who never rebook cost clinics real money and nobody notices in the moment. Deterministic job IDs make retries idempotent, so no patient gets the same message twice; tenant-scoped repositories make cross-clinic data access structurally impossible; PHI-minimized payloads keep the queue safe to inspect.

Why this stack

TypeScript end to end so the risk engine's types flow straight into the UI without a serialization boundary to maintain. The Monte Carlo simulation runs in plain TypeScript rather than a separate Python service — one deploy, no cross-service latency, no second runtime to operate. The AI layer only writes bounded explanations of numbers the engine already computed.

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.

Business impact

The business problem is pipeline reviews running on optimistic gut feel, where a single revenue number hides every assumption behind it. Konstellation gives sales leadership forecast ranges with visible drivers, so people can challenge a deal instead of a spreadsheet cell — and every AI recommendation cites its deterministic factors, so nothing rests on model vibes.

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

The tempting design was an LLM judging the coding agent's diff. I rejected it: a model reviewing a model is unauditable, costs money on every run and can be argued with. A deterministic verifier is free, runs in milliseconds and gives the same verdict for the same diff — which is the entire point of a review boundary.

Business impact

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

No AI in the clinical path for v1, deliberately. A care workspace earns trust with boring correctness — ownership checks, audit events, rate limits — before any assistant shows up. I also skipped native mobile apps: one responsive web workspace, because two extra build targets buy polish, not patient continuity.

Business impact

The business problem is patients getting lost between forms, scheduling links and portals — and clinics absorbing that confusion by phone. Vela gives each patient one workspace with an explicit next action, and because every query is ownership-verified, one clinic structurally cannot page through another clinic's records, even with a forged request.

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

There is no LLM anywhere in project-atlas — a stress engine's entire credibility is reproducibility, and a model in the loop would poison that. I also refused point estimates as outputs: everything ships as a distribution with explicit assumptions, or it doesn't ship.

Business impact

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 local-first Node.js CLI because job-search data is personal: nothing leaves the machine, and there is no server to pay for or secure. CSV as the storage format because the real artifact is a decision table you can open in any spreadsheet. Codex assistance exists, but only behind explicit approval gates — the default path is fully deterministic.

What I decided not to build

I refused to build auto-apply. Mass-submitting AI-generated applications is how you burn a reputation at scale, so CareerOS ranks and prepares while a human decides. Scoring is deterministic before any AI touches an opportunity — the ranking has to be explainable, or it can't be trusted with your career.

Business impact

The business problem is a personal one every job seeker knows: noisy feeds, duplicate listings and hours of application effort spent before fit is even understood. Deduplication plus multidimensional scoring means diligence effort only goes to ranked leads, and the skill-gap report turns each rejection into a concrete roadmap instead of a mood.