Spec-First Engineering — Four Projects, One Discipline
Every project below started the same way: a precise written specification (a 14-rule pivot algorithm, a broadcast scene list, a costed backtest pipeline, a 19-concept indicator checklist) and the requirement to implement it exactly — with tests, screenshots and handover docs. Client names, domains and credentials are never disclosed; all screenshots are real renders of the deliverables.
Market Structure Detection Module (14-Rule Spec, S1–S14)
A private research group supplied an exact 14-rule specification for detecting market structure on OHLCV candles — two layers of events: candidate pivot points from a candle-counting rule, and confirmed structure highs/lows that are only confirmed when price revisits the prior extreme, labeled HH/HL/LH/LL.
The hard part
Two entry points had to produce identical output:
run(bars) (batch) and on_bar(bar) (streaming) — and an
event, once emitted, could never be revised. That means every rule is evaluated
at its knowability bar (S9), and candidate anchoring uses only data up to
the forming bar (S8). The batch mode is literally a replay of the streaming engine —
no duplicated logic, no drift.
Checkpoint flow (as required)
L1 detection → 3 charts → client review → L2 → 3 charts → review → L3 → 3 charts → review → final delivery. Each milestone shipped with chart artifacts so misreadings of the spec were caught in days, not at the end of the contract.
| Rule | Implementation essence |
|---|---|
| S1 / S2 | Inside bars excluded from counting; body direction (c/o) drives runs; doji configurable |
| S3 / S4 | Progress on close; non-progress restarts run; chain measured vs mother bar |
| S6 / S7 | Run qualifies at min_run; opposing qualified run forms the candidate |
| S8 / S9 | Anchor to extreme ≤ forming bar; every event carries its knowability bar |
| S10–S12 | Revisit (wick/close) confirms pair + intervening extreme; supersede, never revise |
| S13 / S14 | Standing levels persist until next revisit; labels HH/HL/LH/LL vs prior same-side |
Broadcast Production System for Live Trading Shows
A proprietary trading firm wanted financial-TV-grade streaming — Tradeify/Bloomberg energy, not gamer neon. The spec: 7–9 scenes at 1920×1080, a full chrome kit (LIVE pill, dual-timezone clocks, nameplates, Coming-Up-Next, lower thirds, watermark), and live data widgets where "static fake prices are a fail".
Stack decision
Restream Studio alone cannot pixel-control a custom
HTML layer. The system runs OBS Studio with browser-source overlays →
Restream multistream: one overlay.html per scene, chrome as
CSS tokens, keyboard-accessible operator pin panel. Producer runbook + Loom
walkthrough + live test session — turnkey, per the brief.
Live data layer — free & keyless
Ticker from the public Yahoo Finance chart endpoint
(no key) with TradingView tape fallback; macro crawl from the ForexFactory calendar
mirror JSON plus an overlay-news.json operator override (the "RSS feed
+ manual override is fine" clause, exactly as allowed). Every price is a live
endpoint — nothing screenshotted.
In the frame: branded ticker strip (indices + FX + crypto, live), LIVE pill with pulse, ET + second-timezone clocks, show title bar, segment cue, two camera plates with nameplates and hand badges, screen-share chart with key level + watermark, macro wire crawl with importance flags, and the right rail operator pin panel — the direct answer to "static fake prices are a fail".
Crypto Backtest Engine — Faithful Implementation, Honest Numbers
A quant client specified two predefined systematic strategies and historical KuCoin OHLCV data. Phase 1 was research only — signal generation with rejection logging, position sizing, fees/slippage/funding assumptions, backtest → out-of-sample validation, and expectancy / drawdown / MAE-MFE reporting.
No look-ahead, by construction
Closed-bar signals only; fills at the next bar open. Parameters frozen on the first 70% window; results reported on the untouched last 30% — and the IS→OOS decay is published, not hidden. Survivorship: only pairs alive across the full window, documented.
Every cost on the ledger
Taker fee 0.10%, slippage capped in bps by its own volatility model, funding accruing on the exchange's 8-hour schedule. MAE/MFE per trade — the two numbers that prove why a stop sits where it sits.
One screen the client can trust: IS equity handing over to OOS (solid/dashed), drawdown over the OOS window, net return OOS +47.8% vs IS +91.2% (decay 0.52 published), Sharpe 1.31, expectancy $41.20/trade, avg MAE −1.12R / MFE +2.71R — and a rejection log that records every dropped signal with a machine reason (min_confidence, max_spread, cooldown, exchange_pause, funding_spike, illiquidity). The engine analyzes 4× the signals it takes.
ICT/SMC Indicator Suite with Volume Profile (Non-Repainting)
A TradingView client's checklist read like an exam: BOS/CHoCH/MSS, BSL/SSL, liquidity sweeps, EQH/EQL, FVG/IFVG, order blocks, breaker blocks, displacement, premium/discount, OTE, killzones, London/NY sessions, SMT divergence, Po3 (AMD), daily/weekly bias — plus the full Volume Profile set (POC, VAH/VAL, PDAH/PDL, PWPOC, HVN/LVN) and one hard rule: no repainting.
Concept → precision rule audit
Before a line of Pine: every concept becomes a 4-column rule table — what qualifies, what confirms, does it repaint. That table is both the proposal and the spec. E.g. liquidity sweep = wick takes out prior EQH then body closes back inside the swept range — close-confirmed, label after close, zero repaint.
Repaint prevention, in code terms
request.security(... barmerge.gaps_off,
lookahead=barmerge.lookahead_off), MTF keys resolved at bar close, alerts
fired only on confirmed closes, and any "live preview" drawing behind an explicit
toggle so the default export never repaints.
| Concept | Qualifying condition | Repaints? |
|---|---|---|
| Liquidity sweep | Wick exceeds prior EQH; body closes back inside swept range | No — label after close |
| BOS / CHoCH | Close beyond prior confirmed swing (fractal); CHoCH = break against trend | No |
| MSS | CHoCH + expansion body > 2× ATR(14) | No |
| FVG / IFVG | Gap between candle-1 high and candle-3 low; IFVG when gap stays alive | Draw at close only |
| Order block | Sibling candle before displaced move; invalidate >50% retrace | No |
| Killzones / SMT | London 08–11 ET, NY 13:30–16:00 ET; SMT = opposite extremes on correlated ticker | No |
| Volume profile | Rolling 150-bar histogram; POC outward → 70% value area (VAH/VAL) | No |
How I Work — the Same Loop for Every Project
Every spec bullet becomes a named, testable rule. If it can't be tested, it's an idea, not a rule. (14 rules → 14 tests; 19 concepts → 19 rules.)
Each level ships with artifacts a human reviews — charts, wireframes, dashboards — before the next level starts.
Batch ≡ streaming. IS→OOS honesty. Append-only event streams. Repaint audits. Every claim is a test, not a promise.
README rule maps, runbooks, walkthrough videos — the client's team maintains the work after handover, so I build for that reader.
Keyless public endpoints with caveats documented where they belong; prototype data labeled as prototype data.
Capability Matrix
| Domain | Evidence |
|---|---|
| Python 3.11 quant engineering (stdlib, streaming state machines) | Market structure engine |
| Broadcasting — OBS, Restream, HTML browser-source widgets | Broadcast system |
| Keyless live-data integration (Yahoo, ForexFactory mirror, KuCoin, ECB) | Broadcast + backtest |
| Backtesting, costs modeling, IS/OOS discipline | Crypto engine |
| Pine Script v5/v6, MTF, non-repaint, volume profile | ICT/SMC indicator |
| Full-stack web (PHP/JS), SEO systems, programmatic pages | This platform + supporting work |
Frequently Asked Questions
What kind of engineering projects do you take on?
Any project with a mechanically verifiable output: quant research modules, systematic trading software, backtest and analytics dashboards, broadcasting/live-trading production, TradingView indicators, full-stack platforms and SEO systems. Fixed scope, fixed price, documented checkpoints.
How do you keep a streaming algorithm identical to batch?
Both modes replay one rule interpreter. Batch is implemented as a replay of the streaming entry point over the fixture — no separate logic path to drift. Plus append-only event streams: an event is emitted at its knowability bar and never mutated afterward.
How are screenshots in this case study produced?
They are real renders of the actual deliverable files (headless-browser captures at full resolution), not mockups gathered from stock sources. All prototype data is labeled as such.
Do you disclose client names?
Never. Client names, domains, accounts and credentials are not published in any portfolio piece. Descriptions are generalized ("private research group", "proprietary trading firm") — many contracts carry confidentiality clauses by requirement.
How do you prevent repainting in Pine Script?
Closed-bar decision points only, lookahead_off on all request.security calls, alerts fired on confirmed closes, and live-preview drawings behind an explicit toggle so the default export is non-repainting by construction.
Do you only build core logic, or the full product?
Full product. Spec → implementation → tests → documentation → handover runbook → live test session. The four projects above each shipped the complete package, not just the algorithmic core.
Have a similar spec on your desk?
Send the specification — I'll return the rule table, the milestones and a fixed price. This is the same discipline that builds custom MT5 Expert Advisors and free quantitative trading tools.
Request a Fixed-Price QuoteGo from article to implementation
Read the proof, then test the idea with calculators, free tools, case studies and a fixed-price build path.