08Engineering Decisions

Why I built it this way.

Every technology choice solved a real engineering problem. Nothing was selected because it was fashionable.

D01
Optimize for Iteration
TanStack Start

Chosen for fast builds, server functions, and a simple architecture so product iteration stays fast without framework lock-in.

D02
Latency Before Infrastructure
Cloudflare Workers

Global execution and extremely low cold-start latency fit real-time market intelligence better than traditional serverless deployments.

D03
Build the Product, Not the Plumbing
Supabase

Realtime database, authentication, scheduling, security, and storage let development focus on trading intelligence instead of infrastructure.

D04
One AI Gateway, Many Models
Lovable AI Gateway

A single AI integration layer provides model flexibility, consistent behavior, centralized governance, and cost visibility across every agent.

D05
Reliable Data Over Easy Data
Firecrawl

When financial websites don't expose APIs, reliable structured extraction becomes more valuable than fragile scraping pipelines.

D06
Concurrency Without Complexity
Postgres

The database became the synchronization layer using transactions, locking, idempotency, and conflict handling instead of introducing additional infrastructure.

Architectural Decision

Why a multi-agent architecture?

The easiest path would have been to hand every question to a single large model and trust the output. It would have shipped faster. It would also have been impossible to defend when things went wrong.

Instead, EdgeQuant separates intelligence into specialised systems. Different agents own different responsibilities: market analysis, prediction, risk, portfolio construction, governance, learning, deployment, and validation. Each has a narrow mandate, a clear input contract, and an output that another agent is allowed to challenge.

That separation is not academic. It produces higher explainability because every decision can be attributed to the agents that shaped it. It produces better governance because no single model is trusted to be right about everything. It makes validation tractable, because a narrow agent can be tested against a narrow expectation rather than a vague notion of "good."

It also produces stronger reliability. When one agent degrades, its scope of damage is bounded and the surrounding system notices. And it produces continuous improvement, because each agent can be measured, retrained, and replaced on its own without rebuilding the platform around it.

One model that does everything is a black box. A committee of specialists is a system you can actually operate.

What the Stack Taught Us

The failures came from every layer.

Every technology choice in the list above was tested by real failures. Supabase saved months of infrastructure work, then taught us that a silent database conflict can swallow two days of predictions. Cloudflare Workers gave us low latency, then taught us that worker timeouts and cold starts still matter. Firecrawl turned unstructured websites into structured data, then taught us that extraction schemas are fragile and that a single site redesign can break a pipeline. Cron looked simple until a scheduled job produced no errors and no trades for eleven days.

The AI gateway unified model access, but models themselves became another failure surface. Claude, ChatGPT, and Gemini each have different latency profiles, rate limits, and failure modes. Building multi-model failover was not a nice-to-have. It was the only way to keep the system responsive when a provider degraded.

These issues are not footnotes. They are the reason the architecture looks the way it does. The separation between intelligence and execution, the obsessive telemetry, the rollback gates, and the runtime evidence bar all exist because the stack failed often enough to make them non-negotiable.