Neuberg: Open-Source Multi-Market Trading Terminal Built with Claude AI

What Neuberg Is

Neuberg is an open-source, browser-based trading terminal built to consolidate multiple trading interfaces into one application. It connects to real markets including Hyperliquid, Polymarket, and Alpaca, normalizes orders internally, and layers news plus structured signals on top.

Where Claude Was Strong

1. Designing Cross-Venue Order Abstraction

Claude helped design a normalized internal format for handling different venues with varying auth models, precision rules, order semantics, and rate limits. The architecture evolved to: OrderIntent → VenueAdapter → API call.

Claude excelled at:

• Identifying edge cases like partial fills, precision truncation, and idempotency
• Suggesting adapter isolation patterns
• Spotting where coupling would become problematic
• Proposing consistent error-surface designs

It performed best when real API docs were pasted in, actual constraints were described clearly, and it was asked to critique a proposed design rather than invent one from scratch.

2. Refactoring Without Breaking Mental Models

As the project grew, Claude helped with:

• Unifying market models across perps, equities, and prediction markets
• Decoupling UI state from the transport layer
• Reducing re-renders during high-frequency websocket updates

Specific contributions included explaining why certain React patterns would trigger cascading renders, suggesting memoization boundaries, and helping restructure state so high-volume order book diffs wouldn't freeze the UI.

3. Structured News + Signal Layer Design

Neuberg pulls in EDGAR Form 4 filings, macro calendar data, venue data, and general financial news. Claude helped design:

• A simple sentiment tagging pipeline
• Entity extraction for tickers, sectors, and geopolitics
• "Impact tagging" heuristics

When prompted with "Given this structured JSON schema, what minimal scoring system would avoid overfitting and still be explainable?", Claude consistently leaned toward simpler, interpretable systems instead of overengineering.

Where Claude Struggled or Needed Adaptation

1. Long Context + Rapid Iteration

For large multi-file changes, context window management became an issue. Claude would occasionally reintroduce patterns that had already been ruled out. What helped was maintaining a short architectural "ground truth" doc, pasting only relevant modules, and explicitly restating constraints.

2. Real-Time Systems Nuances

For websocket diff logic and high-frequency order book updates, Claude sometimes defaulted to abstractions that were clean but impractical, and underweighted performance implications. It needed explicit constraints like "assume 50 updates/sec", "assume 5000 levels", and "optimize for minimal GC pressure" to adapt effectively.

3. Security Boundaries

For trading software involving real money and API keys, Claude's suggestions around security were never accepted blindly, particularly regarding key handling, client/server trust assumptions, and auth storage. While useful for enumerating threat surfaces, security-sensitive decisions still needed validation against best practices.

Key Insight About Using Claude for Infrastructure

Claude was strongest when used for architectural critique, edge-case enumeration, refactoring clarity, and explaining trade-offs. It was weaker when it had to guess unstated constraints, was expected to remember the entire system, or was tasked with inventing designs from scratch without clear parameters.