DEV Community: FoxyyyBusiness

Three crypto exchange volume bugs that were hiding in plain sight

FoxyyyBusiness — Thu, 09 Apr 2026 23:03:30 +0000

I run a service that pulls funding rates from 16 perpetual futures exchanges every five minutes and exposes a unified API for cross-venue arbitrage. Each fetcher is ~50 lines of Python — request, parse, normalize, store. Boring stuff, in theory.

In practice, three of those 50-line fetchers were silently broken in ways that produced plausible-looking numbers. My unit tests passed. The data looked sane. But when I added a simple /api/funding/by_volume endpoint that ranks base coins by their total cross-exchange 24h dollar volume, the leaderboard came back with SATS showing $180 trillion in daily turnover.

That number is roughly the entire global stock-and-bond market, traded in one day, in one shitcoin, on perpetual futures. Something was off.

Here are the three bugs I dug out, in the order I found them.

Bug #1 — OKX is denominated in BASE coin, not USDT

OKX's /api/v5/market/tickers?instType=SWAP endpoint returns a volCcy24h field for every perp. The name reads like "volume in counter currency" — i.e. the quote, USDT. That's how Binance, Bybit, Bitget, Gate.io, MEXC, and most others structure it.

OKX does not. For SWAPs, volCcy24h is in base coin units.

So my fetcher was treating 138000 (138k BTC traded in 24h, which is correct) as $138k in USD volume. OKX BTC volume came back as $136k against Binance's $16.5B. I had been staring at this in the dashboard for two days without noticing because BTC was already at the top of the list — the ranking was right, the magnitude was off by five orders of magnitude.

The fix is one line:

def _okx_tickers() -> dict[str, dict]:
    r = requests.get("https://www.okx.com/api/v5/market/tickers",
                     params={"instType": "SWAP"}, timeout=10)
    out = {}
    for item in r.json().get("data", []) or []:
        inst = item.get("instId", "")
        base_vol = float(item.get("volCcy24h", 0) or 0)
        last     = float(item.get("last", 0) or 0)
        # volCcy24h is in BASE coin units for SWAPs — multiply by last price for USD.
        vol_usd  = base_vol * last
        out[inst] = {"vol_usd": vol_usd, "last": last}
    return out

After the fix, OKX BTC volume jumped from $136k to $9.7B. That matches every other public reporter (CoinGecko, Coinglass, etc).

Lesson: field names are descriptions, not contracts. Read the docs, but trust the cross-exchange comparison even more.

Bug #2 — BTSE counts CONTRACTS, not coins

BTSE's /futures/api/v2.1/market_summary returns a volume field for each market. It is, like everywhere else, a number. But it's not a number of base coins. It's a number of contracts.

A contract on BTSE has a configurable contractSize. For BTC perps, the contract size is 0.001. For some alts, it's 1. For some new perps, it's a weird fraction like 0.0001. The volume field is the count of contracts traded — and the actual notional in base coin units is volume * contractSize.

I had defaulted my BTSE fetcher to assuming one contract = one base coin (a reasonable Binance-shaped assumption). Result: BTSE BTC was reporting $60 trillion of 24h volume, because I was interpreting 1 million contracts (= 1000 BTC) as 1 million BTC.

The fix:

vol_contracts = float(m.get("volume", 0) or 0)
contract_size = float(m.get("contractSize", 1) or 1)
vol_base_units = vol_contracts * contract_size
vol_usd = vol_base_units * mark_price

After the fix: BTSE BTC ~$0.6B per day. That matches BTSE's own published volume widget on their landing page, which I should have checked first.

Lesson: any time an exchange exposes a contractSize field, you almost certainly have to apply it. Even if the default for BTC happens to be 1 on the venue you tested first.

Bug #3 — Kraken Futures funding rate is in dollars, not percent

This one was the most expensive bug because it took the longest to notice.

Kraken Futures' /derivatives/api/v3/tickers endpoint returns a fundingRate field. Every other exchange I integrate (16 of them now) returns this as a decimal: 0.0001 means 0.01% per funding period. Annualized at 8h funding intervals, that's about 11% APY. Sane.

Kraken Futures does not. Their fundingRate is the USD payment per contract per period. So a Kraken fundingRate of 7.0 doesn't mean 700% per period — it means $7 paid per contract held over the funding period.

To convert to a comparable decimal rate, you divide by the mark price:

# Kraken Futures returns fundingRate as USD-per-contract per period.
# Divide by mark price to get the normalized decimal rate.
rate = raw_rate / mark_price

The bug was visible in my dashboard for over a day before I caught it. Kraken ETH was showing 1893% APY — clearly wrong, but it sat in the "extreme rates" view alongside legitimately weird shitcoin funding rates (some alts genuinely run at hundreds of percent), so it didn't pop out. After the fix, Kraken ETH funding came back to ~7% APY, which lines up with the rest of the market.

Lesson: extreme outliers in financial data are sometimes real, sometimes wrong, and almost always worth a five-minute manual sanity check before you ship.

The one-line sanity check that catches all three

Here's the trick I now run after every new exchange integration:

For BTC, sort all exchanges by 24h volume in USD. The numbers should be within one order of magnitude of each other, and no single exchange should be more than ~5x larger than the median.

Concretely:

btc_rows = [r for r in rows if r["base"] == "BTC"]
btc_rows.sort(key=lambda r: -r["volume_24h_usd"])
for r in btc_rows:
    print(f"{r['exchange']:12s} ${r['volume_24h_usd']:>15,.0f}")

What healthy looks like (at the time of writing, end of March 2026):

binance      $ 17,960,723,449
okx          $  9,153,894,221
bybit        $  7,983,221,887
gateio       $  6,510,448,775
bitget       $  4,869,514,230
hyperliquid  $  3,420,118,002
mexc         $  2,914,702,118
bingx        $  1,822,978,884
htx          $    902,541,003
btse         $    614,923,937
phemex       $    321,108,775
kucoin       $    298,992,881
bitfinex     $    132,414,498
kraken       $    101,302,440
bitmex       $     78,200,116
dydx         $     45,109,332

Three properties:

The leader (Binance) is about 250x the smallest entrant (dYdX) — that's the realistic span of CEX/DEX liquidity for the dominant pair.
There are no zeros, and there are no $1T entries.
The shape of the curve is roughly log-linear when plotted, which is what you'd expect from the long tail of crypto venues.

If any single exchange comes back with three more zeros than its neighbors, you have a unit bug. If it comes back with three fewer zeros, same thing. Both my OKX and BTSE bugs were instantly visible in this view — I just hadn't built the view until after the bugs had been live for two days.

For funding rates, the equivalent sanity check is:

No exchange's funding rate for a major (BTC/ETH/SOL) should annualize to more than ±100%. If one does, you have a normalization bug or the venue is in liquidation.

A 1893% APY does not survive this filter. Build the filter first.

What I changed in my workflow

After fixing these three I added two things to the integration template for any new exchange:

A regression test that pins the unit semantics, not just the happy path. For example, my OKX test now constructs a ticker with volCcy24h: "138000" and last: "70000" and asserts that vol_usd equals 138_000 * 70_000, NOT just that the function returns a non-empty dict. If a future refactor accidentally drops the multiplication, the test fails.
A post-deploy cross-exchange diff check that runs after every collector restart. It pulls the BTC volume across all exchanges and screams if any single one is more than 50x or less than 1/50th of the median. It's a 30-line cron job and it would have caught all three of my bugs within five minutes of deployment.

Both of these are straightforward, but they're easy to skip when you're heads-down adding venues. I skipped them, and it cost me two days of looking at a leaderboard with SATS showing $180T in volume and thinking "huh, that's weird, I'll deal with it later."

The bugs were never in the parsing code. They were in the units of the inputs. The exchanges that ship the cleanest documentation and most consistent field semantics make this kind of normalization invisible. The exchanges that don't will silently corrupt your dashboard until the day you build a leaderboard.

If you're aggregating data across venues, build the leaderboard first.

If you found this useful and you're trading crypto perps, the dashboard I was debugging is live at https://fundingfinder.foxyyy.com (free tier, no signup) — it now covers 16 exchanges and ~6,200 USDT-margined perps with five-minute refresh. The fixes from this article are deployed in v0.6.10.

5 boring patterns I used to ship two production services on a $5 VPS in 10 days

FoxyyyBusiness — Thu, 09 Apr 2026 22:58:05 +0000

In the last 10 days I shipped two production web services on a single $5 Hetzner VPS:

Funding Finder — a 20-exchange perpetual futures funding rate aggregator. ~6,800 USDT-margined symbols, refreshed every 5 minutes. 5 systemd services, ~80 MB resident memory.
cronviz — a stdlib-only CLI tool for unified cron + systemd timer observability. Zero dependencies. 48 unit tests.

Both shipped with the same boring stack: Python 3.12 + Flask + SQLite (WAL mode) + systemd + vanilla HTML. Nothing exotic. Nothing trendy. Things that have worked since 2010.

This post is 5 patterns from that work. They're not the only thing I used — there are about 25 more in the full collection — but they're the 5 that did the most leverage. If you're a solo dev shipping a side project on weekends and you keep getting told you need Postgres / Redis / Docker / Kubernetes / FastAPI / asyncio to be "production-ready", read these first. You probably don't.

Each pattern follows the same shape: the pain it solves, the code, when not to use it, and a real number from production.

1. The 12-line systemd unit

You wrote a Flask app. It runs locally with python app.py. You SSH into the VPS, git pull, and now you need it to run forever: restart on crash, restart on reboot, log to a place you can tail -f, let you systemctl restart it on deploy.

Half the internet will tell you to use Docker. On a $5 VPS, for one process, Docker is overkill. systemd has been on every Linux box since 2015 and does exactly this in 12 lines.

/etc/systemd/system/myapp.service:

[Unit]
Description=My Flask app
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/root/myapp
ExecStart=/usr/bin/python3 /root/myapp/app.py
Restart=on-failure
RestartSec=3
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl enable --now myapp.service
journalctl -u myapp.service -f       # logs
systemctl restart myapp.service       # deploy

That's it. There's nothing else.

When NOT to use it. If you need rolling deploys, multiple replicas, cross-machine service discovery, or you're already on Kubernetes — skip this. For literally anything below that bar, this is the right shape.

Production number. My Funding Finder API service has been running for 10+ days, ~25 MB resident memory, 12 restarts (all from systemctl restart during deploys, zero from crashes).

2. SQLite in WAL mode is enough for almost any solo project

You picked SQLite because you didn't want to run a separate database process. Then you started writing concurrently from a Flask request handler and a background collector, and SQLite locked up.

The fix is two PRAGMAs:

import sqlite3
from contextlib import contextmanager

@contextmanager
def conn():
    c = sqlite3.connect("/var/data/myapp.db")
    c.row_factory = sqlite3.Row
    c.execute("PRAGMA journal_mode=WAL")
    c.execute("PRAGMA synchronous=NORMAL")
    try:
        yield c
        c.commit()
    finally:
        c.close()

WAL means concurrent reads no longer block writes (and vice versa). synchronous=NORMAL means SQLite calls fsync() once per commit instead of once per page write — throughput goes from ~100 commits/sec to ~10,000 commits/sec on a typical SSD, and you only lose the last in-flight transaction in the (rare) case of a hard kernel crash.

When NOT to use it. Networked filesystems (NFS): WAL is broken there. Use Postgres. Multi-machine deployments: same answer.

Production number. My collector inserts ~6,800 rows in one transaction every 5 minutes. With WAL: ~80 ms per batch, API server reads never block. Without WAL: random 500s during commit windows.

3. Per-IP rate limiting in 25 lines, no Redis

You opened your free-tier API to the public. Within hours, one IP starts hammering it 50 req/sec. You need to throttle without (a) blocking entirely, (b) running Redis, (c) installing a "professional" rate limiting library that needs a year of config.

import time
from collections import deque
from threading import Lock
from flask import request, abort

_hits: dict[str, deque] = {}
_lock = Lock()
_WINDOW_SECONDS = 60
_MAX_PER_WINDOW = 60   # 60 req/min/IP

def rate_limit():
    ip = request.headers.get("X-Forwarded-For", request.remote_addr) or "unknown"
    now = time.time()
    cutoff = now - _WINDOW_SECONDS
    with _lock:
        dq = _hits.setdefault(ip, deque())
        while dq and dq[0] < cutoff:
            dq.popleft()
        if len(dq) >= _MAX_PER_WINDOW:
            retry = int(dq[0] + _WINDOW_SECONDS - now) + 1
            abort(429, description=f"rate limit, retry in {retry}s")
        dq.append(now)

@app.route("/api/expensive")
def api_expensive():
    rate_limit()
    return jsonify(...)

Each IP gets a deque of recent timestamps. Drop expired ones, count, abort if over the limit, otherwise append. ~25 lines, one global dict, one lock.

When NOT to use it. Multi-process deployments (gunicorn --workers=4) where each worker has its own dict and the limit becomes per-worker. The fix is gunicorn --workers=1 --threads=8 (fine for I/O-bound services), or move to Redis.

Production number. My free tier is 60 req/min/IP, paid tiers are 600 and 3000 req/min. 10 days, 10k+ unique IPs, ~5 MB total memory cost across all the tracked deques. Zero issues.

4. ThreadPoolExecutor for fan-out HTTP fetching, when async is overkill

You need to fetch funding rates for 285 OKX perpetual contracts. The exchange rate-limits public endpoints to ~10 req/s. Your options:

Sequential. 285 × 100 ms = 28.5 seconds. Too slow.
aiohttp + asyncio.gather. Fast, but you're now rewriting the codebase in async def, your tests need pytest-asyncio, your stack traces are 80% framework noise, and you're debugging "RuntimeError: This event loop is already running" in REPL sessions.
concurrent.futures.ThreadPoolExecutor. 8 worker threads, 8 seconds end-to-end, zero new dependencies, your code stays synchronous.

from concurrent.futures import ThreadPoolExecutor, as_completed
import requests

session = requests.Session()
session.headers.update({"User-Agent": "myapp/1.0"})

def fetch_one(inst_id: str) -> dict | None:
    try:
        r = session.get(
            "https://www.okx.com/api/v5/public/funding-rate",
            params={"instId": inst_id},
            timeout=10,
        )
        if r.status_code != 200:
            return None
        rows = r.json().get("data", [])
        return rows[0] if rows else None
    except Exception:
        return None

def fetch_all(inst_ids: list[str], workers: int = 8) -> list[dict]:
    results = []
    with ThreadPoolExecutor(max_workers=workers) as pool:
        futures = {pool.submit(fetch_one, inst): inst for inst in inst_ids}
        for fut in as_completed(futures):
            r = fut.result()
            if r is not None:
                results.append(r)
    return results

Pick worker count just below (rate_limit_per_sec × p95_latency_seconds) × 2. For OKX (10 req/s, 150 ms median): 8 workers, comfortably under the limit.

When NOT to use it. CPU-bound work (the GIL doesn't help — use ProcessPoolExecutor or NumPy). Or millions of concurrent connections (~1 MB stack per thread; 10k threads = 10 GB RAM — use async). For "fan out 100-500 HTTP calls under a rate limit", threads are the boring, working answer.

Production number. My OKX fetcher: 285 instruments, 8 worker threads, ~8 seconds end-to-end, < 0.1% failure rate over 10 days. The async version would shave ~3 seconds off and require rewriting half my codebase. Not worth it.

5. Telegram bot as monitoring transport — €0/month

Your service crashes at 3 AM. PagerDuty exists for this and costs €19/user/month. Telegram exists for this and costs €0.

Setup (90 seconds):

Open Telegram, search @BotFather, send /newbot. Get a token.
Send your new bot a message (you must message it first, before it can message you).
Visit https://api.telegram.org/bot<TOKEN>/getUpdates and find "chat":{"id":12345678}.

Code:

import os
import requests

TOKEN = os.environ.get("TELEGRAM_BOT_TOKEN")
CHAT_ID = os.environ.get("TELEGRAM_CHAT_ID")

def send_alert(message: str) -> bool:
    if not (TOKEN and CHAT_ID):
        return False
    try:
        r = requests.post(
            f"https://api.telegram.org/bot{TOKEN}/sendMessage",
            data={"chat_id": CHAT_ID, "text": message, "parse_mode": "Markdown"},
            timeout=10,
        )
        return r.json().get("ok", False)
    except Exception:
        return False

Use it from anywhere:

if disk_usage > 0.9:
    send_alert(f"⚠️ disk at {disk_usage:.0%} on `{hostname}`")

if collector_age > 600:
    send_alert(f"❌ collector stale: last fetch {collector_age}s ago")

send_alert(f"✅ deploy of `{commit_sha[:7]}` complete")

Your phone buzzes within 2 seconds. No SaaS account, no SDK, no webhook UI, no escalation policy.

When NOT to use it. On-call rotation. Acknowledgment + escalation. Compliance audit trails. > 30 messages/sec sustained.

Production number. I've used this pattern in every service I've shipped for 3 years. Zero missed alerts. Zero subscription cost. Telegram has not become a product they're trying to monetize — the Bot API has been stable since 2015.

The take-away

Shipping a paid web service on a $5 VPS doesn't require 47 config files, a microservices architecture, or a year of devops yak-shaving. It requires:

One systemd unit per service
SQLite in WAL mode
A 25-line rate limiter
A ThreadPoolExecutor instead of asyncio
A free Telegram bot for alerts

Total dependencies introduced by the 5 patterns above: requests (and even that is optional — you could use urllib.request from stdlib). That's it.

If you're still in "I should learn Kubernetes before I ship anything" mode, please consider that this entire stack costs €5/month, fits on a $5 VPS, has been running two production services for 10 days with zero downtime, and is fundamentally easier to reason about than any "modern" alternative. Use what works. The boring stack works.

Where this comes from

These 5 patterns are extracted from a longer collection I'm putting together: 30 Boring Patterns for Solo Devs Who Ship. The other 25 cover:

Theme 2 — SQLite at solo-dev scale (migrations, backups, single-writer pattern, cursor pagination)
Theme 3 — HTTP and Flask (API key auth with revocation, CSV exports, OpenAPI by hand, vanilla HTML/SVG dashboards)
Theme 4 — More external API patterns (mocked-HTTP testing, the structural sanity check on aggregate output, per-source field normalization)
Theme 5 — Operations and observability (health endpoints, /metrics in 15 lines, make as your only deploy tool)
Theme 6 — Going from free to paid (per-tier rate limiting, Lemon Squeezy vs Stripe, pricing a niche dev tool)

The full pack (standalone HTML + companion code zip) is €19, one-time, no subscription. Live now at http://178.104.60.252:8083/boring-patterns — instant download after checkout via Stripe. The 5 patterns above are the full content of those 5 patterns — no teaser cuts. If they're useful, the other 25 are too. If they're not, you've still got 5 production-tested patterns for free. Patterns are CC BY-SA 4.0, code is MIT, 14-day no-questions refund.

Comments / corrections / "you're wrong about X" replies very welcome.

30 days of solo dev shipping: 9 projects, 1 VPS, no Docker — what I actually learned

FoxyyyBusiness — Thu, 09 Apr 2026 22:53:44 +0000

I'm a solo dev. Over the last 30 days I shipped 9 distinct projects on a single $5 Hetzner VPS, all running concurrently, all publicly accessible right now. Total Docker containers: zero. Total Postgres processes: zero. Total cumulative downtime: zero.

This is a retrospective. Not a Show HN, not a launch announcement, not a "look at my projects" gallery. I want to write down what I actually learned doing this — the bets that paid off, the bets that humbled me, and the framework I converged on by accident around day 12.

If you're a solo dev who keeps reading "ultimate stack for indie hackers" posts and thinking "but I just want to ship something already", this is for you.

The 9 projects in one paragraph

A cross-exchange perpetual futures funding rate scanner across 20 venues (data SaaS, the primary product). A stdlib-only CLI for unified cron and systemd timer observability (an OSS dev tool). An info-product book of 30 production-tested patterns for shipping side projects on a $5 VPS. An autonomous bot that posts hourly funding rate signals to Telegram and a public web feed. An auto-generated daily research blog that templates a structured Markdown post from live data. A directory of 10 trader calculators, each at its own URL for long-tail SEO. A curated directory of infra resources for solo devs. An uptime tracker for the 20 exchanges, with 24h status pages per venue. A packaged historical funding-rate dataset (2.58M rows, daily rebuild, CC BY 4.0). Nine distinct domains, nine distinct customer types, all running on the same Flask + SQLite + systemd stack.

The framework that emerged by accident

I started with one project (the cross-exchange scanner). I assumed I'd spend the full 30 days polishing it. Within ~10 days the scanner had everything it needed technically, and I was about to start working on features that the scanner didn't need because I had nothing else to do. That's the moment I realized the gating items were no longer technical — they were external. Distribution accounts (Reddit, HN, Twitter), payment processor (Lemon Squeezy), domain name. None of these are problems I can code my way out of.

So I parked the scanner and started a second project in a completely different domain. Then a third. By day 18 the framework had crystallized into three rules:

Rule 1 — Park when blocked, not when bored. A "real blocker" is something I cannot resolve alone (a credential, a decision from someone else, a payment, a validation). Not "I want to add another feature". Not "I could improve the test coverage". If I can still write code, prose, tests, or design — that's not a blocker, that's continuation.

Rule 2 — Always have ≥2 projects in flight. When I park a project, I start (or resume) something else immediately. The work queue is never empty. This sounds inefficient but it's actually the opposite: it forces me to never be in the "I'm waiting for X" passive state. There's always a concrete next action.

Rule 3 — When the projects start to look alike, the rule kicks in differently. When I had 3 projects and they were all "Flask data API for crypto", I stopped and asked: am I just rebuilding the same thing in different domains? The answer was yes. So I started forcing the new projects to be structurally different from existing ones — different audience, different distribution model, different format. The 9 projects ended up covering 9 distinct shapes (data SaaS, OSS CLI, info product, autonomous notifications, auto-generated content, calculators, curated directory, status pages, packaged dataset). Each one would teach me something the others couldn't.

I didn't plan this framework. It emerged because the alternative — sitting on one project waiting for credentials — felt obviously wasteful. Once it was named, it became operational.

The boring stack paid off, again

Every project ships with Python 3.12 + Flask + SQLite (WAL mode) + systemd + vanilla HTML. No Docker, no Postgres, no Redis, no Kafka, no asyncio, no frontend framework, no microservices, no API gateway, no serverless functions.

The reason this works is mostly negative: every "modern" thing I avoided has a real cost in setup time, debugging surface, and ongoing maintenance, and the value those things would provide doesn't matter at solo-dev scale. SQLite in WAL mode handles 50,000 commits per second on a $5 VPS with NVMe — every project I built combined uses maybe 200 writes per minute. That's 0.4% of capacity. Postgres would make zero perceptible difference and would add a process to manage, a separate auth surface, a backup story, and a network round-trip for every query.

systemd does the job of Docker for any single-host service. Twelve lines per unit file gets you auto-restart on crash, auto-start on reboot, structured logging via journalctl, and systemctl restart deploys in 3 seconds. I use it for every service I ship and I've never had a moment where I missed Docker.

The most surprising thing about the boring stack is how small it feels. The whole 9-project ecosystem fits in your head. I can hold the entire surface area mentally: 5 systemd services, 1 SQLite file, ~25 HTML pages, ~30 API endpoints, 3 autonomous timers, 80 MB of resident memory total. There are no hidden processes, no opaque containers, no black-box managed services. If something is wrong, I know where to look.

The four bugs that humbled me

While integrating the 20 exchanges, I introduced four silent bugs in my own normalization code that 100% test coverage didn't catch. Each was a unit conversion error and each was off by 5+ orders of magnitude:

OKX volCcy24h is in base coin units, not USDT. I was treating it as USDT. OKX BTC volume came back as $136k against Binance's $16.5B. I'd been staring at this in the dashboard for two days without noticing because BTC was already at the top of the ranking — the order was right, the magnitude was off by 5 orders.
BTSE volume is contract count, not base coin units. Without the contract size multiplier, my BTC volume calc was 5 orders too high. The leaderboard showed BTSE BTC at $60T (>$60 trillion). Anyone who read the dashboard would have noticed instantly. I didn't, because I had no aggregate view.
Kraken Futures fundingRate is USD-per-contract per period, not decimal. Their fundingRate of 7.0 means "$7 per contract per period", not "700% per period". I was treating it as decimal and showing Kraken ETH at 1893% APY for two days.
BitMEX uses XBT internally, not BTC. I'd written XBT→BTC normalization for Kraken and KuCoin (which also use XBT) months earlier, but forgot to add it for BitMEX when I integrated it. BitMEX BTC silently disappeared from cross-venue BTC views for the entire time it was in production. Caught only when I added the 17th venue and noticed the leaderboard had 16 entries instead of 17.

What unifies these four bugs is that none of them were in the parsing code. The parsing code was correct in every case. The bugs were in the assumed semantics of the input. My unit tests were green because they pinned the wrong invariants on hand-written JSON fixtures that I had also gotten wrong.

The thing that finally caught all four was a single 30-line function I started running after every collection cycle: sort BTC volume across all sources, look for any source where the value is more than 50× the median or less than 1/50× the median. If you have an outlier of that magnitude, it's almost always a unit bug. I now run this check in CI for every new exchange integration and it has caught zero false positives and four real bugs.

I wrote this up under the working name "structural sanity check on aggregate output" but I'm not sure that's what it's called. Property-based testing is the closest formal cousin but doesn't quite fit. If anyone has a better name, I'd love it.

What I'd do differently

Start the launch material on day one, not day twenty. I waited until I had products to launch before writing the launch drafts. By the time I wrote them, I had four projects without any distribution material at all — orphans. If I were doing this again, I'd write the Show HN draft for a project the same day I started building it, even before v0.1. The exercise of writing the draft forces clarity about what the project is for.

Build the placeholder-replacement script earlier. I have 70+ placeholders scattered across drafts and static pages (clementslowik, clementslowik, github.com/clementslowik/funding-collector, fundingfinder.foxyyy.com) that all need to be replaced when credentials arrive. I wrote the replacement script in week 4. If I'd written it on day 1, every new draft would have used the placeholder syntax from the start, and the launch-day patching would have been trivial.

Take the credential blockers seriously earlier. I assumed that the credentials (Reddit account, HN karma, GitHub PAT, Lemon Squeezy account) would arrive "soon" and I could focus on the build. They didn't arrive in week 1, then they didn't arrive in week 2, then I started genuinely understanding that the entire monetization pipeline was gated on items I couldn't resolve myself. If I were doing this again, I'd treat credential acquisition as the very first task, not the last.

Write the meta-launch piece earlier. The single Show HN that points at /shipped (the canonical "I shipped 9 projects on a $5 VPS in 30 days" page) is going to be the most important post of the entire 30 days, because it serves as proof for all 9 projects simultaneously. I wrote it on day 30. It should have been drafted on day 5, with the project list updated as new ones shipped.

What I wouldn't change

The 8-projects-in-30-days pace. I expected to feel scattered and unfocused. Instead I feel like I have a much wider sense of what each kind of product feels like to build, which is exactly the kind of generalist intuition you don't get from focusing on one thing. The opportunity cost is real (none of the 8 is maximally polished), but the learning rate is 8x higher than it would have been on one project.

The boring stack discipline. Not once did I think "if only I had Docker" or "this would be easier with Postgres". Every time I was tempted to add a new tool, the question "what specific problem does this solve that I have right now" produced an honest "none". The boring stack saved me weeks of decision fatigue.

The work_queue framework. Having a hard rule of "≥2 projects in flight, park when actually blocked, start something different when bored" turned out to be the productivity hack I needed. Not the sexy productivity hack, the boring one — the one that says you don't need a Pomodoro timer, you need a clear next action.

Try it

Everything I built is publicly accessible right now. If you want to verify any of the claims above:

/shipped — the canonical list of 9 projects with public URLs and metrics: http://178.104.60.252:8083/shipped
/now — the cross-exchange funding rate dashboard: http://178.104.60.252:8083/now
/research/2026-04-09 — today's auto-generated research post
/status — uptime tracker for the 20 exchanges
/boring-patterns — the in-progress patterns book (5 free, 12 more drafted)

Source code for the OSS data collector: pip-installable from http://178.104.60.252:8083/downloads/funding-collector-0.4.3.tar.gz (will move to GitHub when credentials arrive).

If you found this useful, the easiest way to support is to bookmark /now and check it once a day. There's a launch waitlist on every project page if you want the one-time email when the paid tiers go live — no spam, no follow-up sequence, single email.

Comments / corrections / "you're wrong about X" replies are very welcome. The "structural sanity check" pattern naming question in particular is a real ask — if you have a better name for it, I'm reading every reply.