Show IH: LeadEdge — Cross-exchange ETH lag API (validated at 90.7% follow-through)

TL;DR: Built LeadEdge (leadedge.dev), a cross-exchange ETH lag detection API. Before writing the product, I spent 7 days analyzing real crypto exchange data to validate the core thesis. Result: 90.7% follow-through on lag signals. Then shipped the full SaaS in 7 days. Here's the methodology.

The Problem I Was Trying to Solve

I'd noticed something weird while running crypto trading bots: when Binance Futures moved, Coinbase Spot seemed to follow. Anecdotally, it looked like there was a measurable, predictable lag between the two exchanges.

If true, this was the kind of cross-exchange asymmetry that could be productized. But "anecdotal" doesn't pay the bills, and I've watched too many friends ship SaaS products based on gut feel that nobody wanted.

So I made a rule: validate before build. If the data didn't back up the thesis, I'd kill it and move on.

The Validation Setup (7 Days)

I built a minimal data collection pipeline first — no product, no UI, just raw measurement:

• WebSocket connections to Binance Futures and Coinbase Spot for ETH/USDT
• Timestamp normalization (this turned out to be the hardest part — exchange clocks vs receive timestamps create subtle drift)
• Storage: Postgres for the raw event log
• Analysis: Pandas + custom scripts to detect lead/lag relationships

The goal was answering one specific question: "When Binance Futures moves >X%, what % of the time does Coinbase Spot move in the same direction within Y milliseconds?"

What I Found

After 7 days of continuous data collection:

• Median lag: ~150ms (Binance Futures leads Coinbase Spot)
• Follow-through rate at 0.1% threshold: 90.7%
• Direction prediction accuracy: Held across multiple market regimes (trending, choppy, high vol)
• Out-of-sample testing: Validated on a fresh 24-hour window

This was the green light to build.

If the follow-through had been below ~60%, the thesis would've been noise. Above 80%, there was real signal — and at 90.7%, it was a clear edge worth productizing.

Full methodology writeup: leadedge.dev/blog/validation

The Build (Another 7 Days)

With validation done, I shipped the full SaaS in 7 days:

Stack:

• Frontend: Next.js 14 + Tailwind (Vercel)
• Backend: Python signal detection engine (Railway)
• WebSocket Server: Real-time signal pushes to subscribers
• Auth + DB: Supabase (handles OAuth, RLS, and Postgres in one)
• Payments: Stripe + webhooks back to Supabase
• Email: Resend for transactional + drip campaigns

Claude Code did a lot of heavy lifting on the Next.js side — particularly the dashboard components and chart rendering. What used to take a week of UI work was 1-2 days.

Lessons Learned

1. Data collection ≠ product. Don't conflate them.
The temptation is huge to start building the product while you're validating. Resist it. The validation infrastructure is throwaway code; the product is what you'll maintain for years. Mixing them early creates technical debt before you've even confirmed product-market fit.

2. Timestamp normalization is harder than the algorithm itself.
"Exchange timestamp" and "message received timestamp" create subtle alpha leakage everywhere. NautilusTrader's "monotonic across replay and live" design philosophy is genuinely solving a real problem most people don't realize they have until they've burned a strategy on backtest-live drift.

3. The "validation methodology" is more defensible than the "algorithm."
Anyone with a CCXT install can detect cross-exchange lag — that's not the moat. The moat is the rigor of how you measure, validate, and continuously monitor that the signal still works. The methodology is what customers are actually paying for.

4. Silent WebSocket staleness is more dangerous than connection drops.
Connection stays "alive" (TCP keepalive is fine) but messages stop arriving. Took down my pipeline for 40 minutes before I noticed during validation. Now I run message-level heartbeats from day one.

5. Validation BEFORE build = faster build.
Because I'd already debugged the data pipeline during validation, the production version was 60% pre-solved when I started building the product. The Postgres schema, the WebSocket handling, the timestamp normalization — all of it was battle-tested already.

Where I Am Now (Day 3 Post-Launch)

• Live at leadedge.dev
• 2 early signups in week 1 (free tier — first paid conversions still pending)
• $0 MRR — focused on building distribution + nailing the conversion funnel before optimizing pricing
• Early conversations with respected algo trading practitioners and infrastructure builders in the space
• Reddit + Twitter presence building organically
• Working on Freqtrade integration to lower adoption barrier

Long road ahead, but the validation rigor up front meant I started from a place of confidence, not hope.

A Note on the Approach

This is my second SaaS — first was jsvisible.com (JavaScript SEO scanner). I shipped that without rigorous pre-validation, just gut feel, and the post-launch growth was slower than expected. That experience is what made me commit to the "validate before build" rule for LeadEdge.

Same solo founder, same stack, same hustle — but a much more disciplined approach to confirming demand before pouring engineering effort in. So far, the difference is showing.

Tools I Used

• CCXT — unified exchange API (saved weeks)
• Claude Code — Next.js dashboard + chart components
• Supabase — auth + Postgres + RLS in one
• Railway — backend deployment, simpler than AWS for a solo founder
• Stripe — payments + webhooks
• Resend — emails
• Recharts — time series charts
• Postgres + Pandas — the validation analysis stack

Happy to answer questions about the validation methodology, the tech stack, or the "validate before build" philosophy. Curious if other indie hackers here have used a similar approach for B2B SaaS — would love to hear what worked vs didn't.