Axis

Co-founder & CTO · San Francisco · Y Combinator–backed · Oct 2025 – Jul 2026

I was the co-founder and CTO of Axis. I built the product’s application layer largely on my own — the data platform behind an agent-assisted research dashboard for commodity markets. Two ideas carry it: keep every provider’s data raw, and let the agent be the layer that normalizes and analyzes it.

What Axis does

The dashboard does the analysis a commodity researcher would otherwise do by hand. An analyst asks a question; the agent pulls the relevant data, reconciles it across sources, runs the numbers, and drafts an answer with its sources attached. It’s a real trading environment where a bad number costs money, so the analyst audits the evidence before acting on it.

The application layer

I own the architecture and most of the core engineering for the application layer:

• Ingestion across many providers. A Python system unifying 13 data providers (~57 endpoints) under one declarative framework: each source declares its endpoints, schedules, and rate limits, and a generic runner executes them all with per-endpoint failure isolation. The hard part isn’t fetching — it’s that every provider has its own schema, units, and revision habits.
• Data stays raw. Every row and field a provider returns is persisted verbatim, before any normalization. No cleanup step gets to decide what’s worth keeping.
• The agent is the normalization layer. Canonicalization — turning each provider’s units and fields into one common form — usually happens up front, which forces every source into a rigid schema. Here it lives in the agent instead, reconciling the differing standards on read, per question. Adding a provider still means a new raw table, but a provider changing a field or unit in a feed it already sends is absorbed on the next read rather than by a backfill, and that’s what keeps this many sources manageable.
• Storage and forecasting. Underneath, a provenance graph over PostgreSQL keeps each fact tied to its source, and a TypeScript service turns the data into forecasts with error bands.
• Ownership. I’ve written ~6,000 commits across three generations of the application, ~90% of the team’s total, and driven the architecture.

Where canonicalization lives. Hover a stage to see what it does:

Core design decisions

One decision drives the rest: keep the data raw. Strict provenance and flexible canonicalization both fall out of that decision rather than standing apart from it. Altogether it comes to roughly ~280K lines of Python and TypeScript, ~140 PostgreSQL tables, and 400+ test files.

• Raw data is never a write gate. Every row and field a provider returns is persisted before any normalization happens; canonicalization is sidecar metadata. Rows that fail to parse land in reject tables with pointers back to the exact raw response and a typed error code, instead of vanishing into a log line.
• Provenance rides along, for free. Because the raw record is always kept, every canonical value traces straight back to it. Corrections supersede rather than overwrite: observations dedup by content hash and revise via supersession chains, with database constraints enforcing one latest row per series, so when a source restates history both versions survive.
• Canonicalization stays flexible because the raw doesn’t move. Since nothing is lost on write, the agent can re-canonicalize on read as a provider’s standards shift or a new source appears — no destructive migration, no re-ingest.
• The agent never touches credentials. A broker service mediates every external fetch the research agent makes, with per-run budgets and rate limits, and freezes fetched evidence to immutable storage so citations keep resolving later.

Things I’d carry forward

• A good skills system for agent-assisted development pays for itself fast.
• Never push late on a weeknight. I was up until 5am debugging more than once, and it was never worth it.
• Set up real CloudWatch alarms early. AWS won’t tell you something’s wrong; you have to ask it to.
• Stay unopinionated as long as you can. The providers, the data, and the questions all changed under us, and the parts we hadn’t hardened yet were the easy ones to move.

Traction

The product reached roughly $60K in annual recurring revenue while still early.

Axis is a proprietary product, so there’s no public code here, and the descriptions above stay at the level of design patterns rather than internals.