← Back to portfolio
Case Study · Commercial Product · Solo Build

LookAhead Trading

formerly Oraculum · lookaheadtrading.com

A subscription trading-signals platform that scans 692 crypto, forex and commodity markets in real time — with its own billing, accounts, alerts and a second macro product served under one domain.

Role
Sole designer & builder
Scope
Backend · Frontend · Infra · Billing
Status
Live, billing enabled
Timeline
Ongoing · 2025–26
01

The brief I set myself

Turn a personal market-scanner into a product people pay for. That means the parts a small team usually splits up, done by one person: a live data engine that never sleeps, subscription billing that survives edge cases, accounts and access tiers, push and email alerts, and an honest way to measure whether the signals are any good.

Partway through, a second product — a macro-intelligence dashboard — had to fold into the same domain and the same login, without duplicating auth or exposing either app's secrets. That constraint shaped most of the architecture below.

02

By the numbers

565+Crypto markets
127Forex & commodities
8 × 5Timeframes × indicators
30 sScan loop
2 → 1Products, one domain
5Access tiers, gated
03

How it fits together

Two independent Python services run behind one public origin. The trading app owns the login, billing and notifications. Any request under /macro is proxied over loopback to the macro service, carrying the signed-in user as an HMAC-signed identity header — so the second app trusts the first directly, with no shared cookie, no second login, and no secret crossing the wire.

Trading dashboard :3330 · public origin Login · Stripe billing · tier gating · Web Push & email alerts · signal API
Supabase · auth + accounts
Stripe · live billing
Bitget · crypto feed
OANDA · forex feed
Macro-intelligence engine :3340 · internal Fed radar · capital-flow & regime scoring · BTC/gold rotation · macro alerts
SQLite · signal history
WebSocket · live prices
CoinGecko · market caps
cron / launchd · always-on
04

Problems worth solving

Unified auth

Two products, one login

A loopback mount serves a second Python app under the same domain and session. The signed-in identity is passed as a short-lived HMAC-signed header, so neither app loads the other's secrets or needs a cross-site handshake.

Billing that holds

Subscription tiers that don't leak

Five access tiers enforced on both server and client. Stripe checkout and webhooks drive upgrades and downgrades, with signature verification, a five-minute replay window, and a backup path so a missed event still lands the right tier.

Security under real money

Found and closed an account-takeover

Identity was being resolved by scanning sessions on a non-unique field, which could serve one user another's account. Fixed to resolve strictly from the authenticated session. A pre-commit scanner now blocks any key from reaching git.

Runs without me

Autonomous, supervised services

Signal engines, the notifier and both apps stay up under a watchdog on cron and launchd, recovering from restarts on their own. Strategy work is validated with walk-forward, intra-bar backtesting rather than flattering close-only numbers.

05

What it demonstrates

Systems integrationAuth, billing, real-time market data and notifications wired into one coherent product across two services.
Security judgementSigned internal identity, webhook verification, secret scanning, and a takeover bug caught and fixed in a live, money-handling app.
Ships and stays shippedA deployed product with paying-tier infrastructure, not a prototype — kept alive by supervised background services.
Domain fluencyMarkets, indicators and honest performance measurement handled with the scepticism the subject demands.
06

Built with

Python JavaScript / TypeScript Supabase · Postgres Stripe Bitget API OANDA API WebSocket feeds SQLite Web Push Resend email Cloudflare Tunnel cron / launchd GitHub OAuth Anthropic API