Forem: FoxyyyBusiness

I shipped 100+ free tools on a $5 VPS in 5 days

FoxyyyBusiness — Sat, 11 Apr 2026 22:23:15 +0000

I've been building foxyyy.com — a collection of 100+ free developer and utility tools running on a single $5 VPS.

The stack

Server: $5 VPS (1 vCPU, 1GB RAM)
Backend: Flask + nginx reverse proxy
Frontend: Pure HTML/CSS/JS — no frameworks, no CDN
Design: Dark theme, monospace fonts, amber accent (#c9a227)
i18n: Client-side EN/FR/ES/DE language selector on every page

What's included (110 tools)

Developer Tools

JSON Formatter, Regex Tester, Base64/JWT Decoder, Hash Generator (MD5/SHA), URL Encoder, HTML Entities, Diff Checker, CSS Minifier, UUID Generator, Timestamp Converter, Markdown Preview, HTTP Status Codes, DNS Lookup, WHOIS Lookup, Cron Explainer, Sitemap Generator, Meta Tag Generator, Robots.txt Generator, Chmod Calculator, IP Subnet Calculator, CSV to JSON, JSON to TypeScript, SQL Formatter, Markdown Table Generator, Binary/Hex/Decimal Converter

Business & Finance (FR)

TVA Calculator, Salaire Net/Brut, Auto-Entrepreneur Simulator, Prêt Immobilier, Mentions Légales Generator, Privacy Policy Generator, Invoice PDF Generator, Stripe Fee Calculator

Content & Media

Color Picker, Palette Generator, Gradient Generator, Placeholder Images, OG Preview, Favicon Generator, Image Resizer, Emoji Picker, Lorem Ipsum (FR/EN), ASCII Art, Typing Speed Test, Word Counter

Utilities

Password Generator, QR Code Generator, Email Deliverability Checker, Pomodoro Timer, Stopwatch, Countdown Timer, IP Lookup, Random Number Generator, Unit Converter, BMI Calculator, Age Calculator, Percentage Calculator, Aspect Ratio Calculator

Combo Dashboards

Dev Toolkit: 6 dev tools in one tabbed interface
SEO Audit: Meta tags + DNS + OG + speed check
Domain Health Check: DNS + WHOIS + Email + SSL
Color Design Suite: Picker + Palette + Gradient + Contrast
Entrepreneur Dashboard: French AE business calculator
Text Suite: Word counter + case converter + diff + lorem + find/replace

Design philosophy

Every tool is a single HTML file. No build step. No npm. The whole thing loads in under 8KB per page. Dark/light theme toggle on every page. Zero tracking, zero ads.

Numbers

110 tools shipped in 5 days
87 HTML files
~600KB total static assets
1 VPS, 1 developer

What's next

More combo dashboards
API endpoints for automation
More languages
Community contributions

Try it: foxyyy.com
Changelog: foxyyy.com/changelog

Built solo. No funding. Just shipping.

6 outils gratuits que j'ai construits pour les auto-entrepreneurs français

FoxyyyBusiness — Fri, 10 Apr 2026 22:46:43 +0000

Je suis développeur et j'ai créé une suite d'outils en ligne gratuits pour les besoins courants des auto-entrepreneurs et freelances en France. Tout est gratuit, sans inscription, sans pub.

Les outils

1. Simulateur de charges auto-entrepreneur

Entrez votre CA mensuel, l'outil calcule :

Charges URSSAF (taux selon votre activité : BNC 21.1%, BIC 21.2%, commerce 12.3%)
Impôt sur le revenu (versement libératoire ou barème progressif)
Net réel après tous les prélèvements
Vue mensuelle et annuelle

→ foxyyy.com/simulateur

2. Calculateur TVA

Conversion instantanée HT ↔ TTC avec les 4 taux français :

20% (normal)
10% (intermédiaire : restauration, transport)
5,5% (réduit : alimentation, énergie)
2,1% (super-réduit : presse, médicaments)

→ foxyyy.com/tva

3. Calculateur salaire net/brut

Convertisseur brut ↔ net pour :

Cadres
Non-cadres
Fonction publique

Avec le détail des prélèvements : sécurité sociale, CSG/CRDS, retraite complémentaire, chômage.

→ foxyyy.com/salaire

4. Générateur de factures PDF

Formulaire → facture PDF conforme :

Mentions obligatoires auto-entrepreneur (article 293B du CGI)
TVA optionnelle
Téléchargement instantané
Aussi disponible en API : POST /api/generate avec un JSON → PDF

→ foxyyy.com/invoice

5. Générateur de mentions légales

Obligatoire pour tout site web en France. L'outil génère des mentions conformes selon votre statut :

Auto-entrepreneur, SARL, SAS, EURL, association
Section RGPD/cookies si applicable
Hébergeur pré-rempli (OVH par défaut)

→ foxyyy.com/legal

6. Politique de confidentialité RGPD

Générateur détaillé avec :

Données collectées (email, nom, IP, cookies...)
Finalités du traitement
Base légale (consentement, contrat, intérêt légitime)
Droits des utilisateurs (accès, rectification, effacement...)
Sous-traitants (Google Analytics, Stripe, Mailchimp...)
Durée de conservation

→ foxyyy.com/privacy

Pourquoi c'est gratuit ?

Ces outils tournent sur un VPS à 5€/mois. Le coût marginal d'un utilisateur supplémentaire est quasi nul. J'ai d'autres produits payants sur la même plateforme (pour les développeurs), mais ces outils business sont et resteront gratuits.

La page hub

Tous les outils FR sont regroupés ici : foxyyy.com/outils-fr

Si vous avez des suggestions d'outils qui manquent pour les indépendants en France, je suis preneur dans les commentaires.

Tous les outils sur foxyyy.com. Code par Clément Slowik.

I shipped 41 tools on a $5 VPS in 4 days — here is everything I learned

FoxyyyBusiness — Fri, 10 Apr 2026 19:22:23 +0000

Four days ago I started a 30-day challenge: ship as many useful tools as possible on a single $5 VPS, using Python + Flask + SQLite + systemd. No Docker, no Kubernetes, no cloud functions.

Today the counter is at 41 tools across 9 categories, all live at foxyyy.com.

What I shipped

Crypto & Trading (the starting point):

Cross-exchange funding rate scanner (20 exchanges, ~6,800 perps)
Autonomous signal alerts bot
Exchange uptime tracker
Historical dataset (2.58M rows, CC BY 4.0)

Developer Tools (the largest category):

Regex Tester — live matching with capture groups
JSON Formatter — validate + pretty-print + minify
Cron Explainer — paste a cron expression, get English
Base64/JWT Decoder — client-side, nothing sent to server
UUID Generator, Timestamp Converter, HTTP Status Codes
Markdown to PDF — paste markdown, download styled A4 PDF
Screenshot API — capture any webpage as PNG
cronviz — OSS CLI for cron/systemd observability

French Business Tools:

Invoice PDF Generator — auto-entrepreneur compliant
Mentions Légales — French legal notice generator
TVA Calculator — all 4 French VAT rates
Salary Net/Brut — cadre/non-cadre converter
Auto-Entrepreneur Simulator — URSSAF + tax → net

Utilities:

Email Checker — SPF/DKIM/DMARC analysis with score
DNS Lookup, WHOIS, IP Lookup
Password Generator with entropy calculation
QR Code Generator — PNG + SVG
Uptime Monitor — 5-min pings
Color Palette, Favicon Generator, Lorem Ipsum FR
Word Counter, Text Case Converter, Pomodoro Timer

And more. Full changelog: foxyyy.com/changelog

The stack

Every tool runs on one $5 OVH VPS (2 vCPU, 2GB RAM):

Python 3.12 + Flask
SQLite (WAL mode) for anything that needs persistence
systemd for every service (17 active units)
nginx as reverse proxy + Let's Encrypt HTTPS
No Docker, no Redis, no Postgres

Total memory usage across all 17 services: ~400 MB. CPU mostly idle.

What I learned

Client-side tools are free to ship. Half of these tools (regex, base64, JSON, UUID, pomodoro, etc.) are pure JavaScript. No server process, no port, no systemd unit. Just an HTML file with <script> tags. Once routed, the cost of hosting them is literally zero.
The boring stack scales to dozens of services. systemd + SQLite + Flask is enough for everything I've built. Each service starts in <1 second, uses ~20-40MB, and auto-restarts on failure.
Distribution is harder than building. I can ship a tool in 30 minutes. Getting 10 people to see it takes 10x longer. My Twitter account has 2 followers. My dev.to profile is brand new. The tools are invisible without external traffic.
A pricing page makes the free tools feel more valuable. Once I added a pricing page that shows "30+ tools are free, 4 are paid", the free tools stopped feeling like side projects and started feeling like a product.

Monetization

4 products have Stripe payment links:

30 Boring Patterns — €19 one-time (production recipes for solo devs)
Flask SaaS Starter Kit — €29 one-time (boilerplate with auth + billing)
Screenshot API Pro — €9/month (higher rate limit)
Email Checker Pro — €5/month (bulk API)

Revenue so far: €0. Day 4. The funnel exists, the traffic doesn't yet.

What's next

26 more days. More tools in more domains. The goal is to find which tool has organic traction and double down on it. Every tool is a lottery ticket — the more I ship, the higher the chance one breaks through.

If you want to explore: foxyyy.com

Built by Clément Slowik. All tools open on foxyyy.com. OSS repos on GitHub.

The funding-rate gotcha that breaks 30% of Python crypto scrapers: per-symbol intervals

FoxyyyBusiness — Fri, 10 Apr 2026 11:27:05 +0000

If you've ever used or written a Python script to scrape crypto perpetual funding rates from Binance, Bybit, Bitget, MEXC, Gate.io, OKX, or Hyperliquid, there's a 70% chance you have a subtle bug that quietly inflates your annualized yields by 2-8x on roughly 30% of symbols.

I'm not exaggerating. I checked.

The bug

Every popular GitHub repo I've found that scrapes funding rates assumes an 8-hour funding interval for every symbol. The annualization is typically computed as:

annualized_yield_pct = funding_rate * 3 * 365 * 100

Where 3 is "3 funding settlements per day" because there are 24 hours in a day and 8 hours per funding period.

This is wrong for ~30% of perpetual symbols on Binance and Bybit, ~25% of Bitget, and 100% of Hyperliquid and dYdX.

Binance has 425 USDT-margined perps on a 4-hour cycle and 4 perps on a 1-hour cycle. Bybit has 377 on 4-hour and 3 on 1-hour. Bitget has a similar mix. Hyperliquid and dYdX v4 are entirely on 1-hour cycles. MEXC even has a few perps on 24-hour cycles.

A 0.05% per-period funding rate is:

55% APY if the symbol is on an 8h cycle
109% APY if it's 4h
438% APY if it's 1h
18% APY if it's 24h

If your scanner shows the same annualized number for all of them — or worse, applies 8h to all of them — you're either over-reporting or under-reporting by 2-8x on roughly a third of your universe. The mistake silently propagates into your "best opportunities" ranking and leads to wasted capital on misranked trades.

How to verify whether your code has the bug

Pick any USDT-margined perp from one of the affected exchanges that has a non-standard interval. A few examples that were on 4h funding intervals as of writing (always check the live values, exchanges shift their cycles):

Binance: many small-cap altcoins, especially recently listed
Bybit: similar pattern
Hyperliquid: literally all of them are 1h

Run your scraper. Look at the symbol's annualized yield. Then manually compute the correct number using the actual funding interval. If they differ by 2x or more, you have the bug.

Or just look for the magic number 3 * 365 (or 1095) in your code. If it's there without a funding_interval_hours lookup nearby, you have the bug.

The fix

Each exchange exposes the funding interval per symbol in a different endpoint, with a different field name, and a different unit. Welcome to crypto data plumbing. Here's the per-exchange fix:

Binance

def _binance_funding_intervals():
    """{symbol: hours}. Cache process-wide, refresh weekly."""
    r = requests.get("https://fapi.binance.com/fapi/v1/fundingInfo", timeout=15)
    return {item["symbol"]: int(item.get("fundingIntervalHours", 8)) for item in r.json()}

The endpoint only returns symbols with non-default intervals (i.e. anything that's not 8h). For symbols not in the response, assume 8h. Cache this dict at startup and refresh once a week — the assignments change rarely.

Bybit

def _bybit_funding_intervals():
    """Bybit returns the interval in MINUTES via instruments-info."""
    out = {}
    cursor = ""
    for _ in range(20):
        params = {"category": "linear", "limit": 1000}
        if cursor:
            params["cursor"] = cursor
        r = requests.get("https://api.bybit.com/v5/market/instruments-info", params=params, timeout=15)
        data = r.json()
        if data.get("retCode") != 0:
            break
        for item in data.get("result", {}).get("list", []):
            sym = item.get("symbol", "")
            minutes = int(item.get("fundingInterval", 480))  # default 8h = 480 min
            out[sym] = max(1, minutes // 60)
        cursor = data.get("result", {}).get("nextPageCursor", "")
        if not cursor:
            break
    return out

Note the unit: minutes. Convert to hours.

Bitget

def _bitget_funding_intervals():
    """Returned in HOURS as fundingRateInterval. Single bulk call."""
    r = requests.get(
        "https://api.bitget.com/api/v2/mix/market/current-fund-rate",
        params={"productType": "usdt-futures"}, timeout=15
    )
    return {item["symbol"]: int(item.get("fundingRateInterval", 8)) for item in r.json().get("data", [])}

Cleanest of the bunch. Bulk endpoint, hours.

MEXC

def _mexc_funding_intervals_inline(funding_rate_response):
    """MEXC bundles the interval into the funding_rate response itself, as `collectCycle`."""
    return {item["symbol"]: int(item.get("collectCycle", 8)) for item in funding_rate_response.get("data", [])}

Inline with the funding rate data — no separate call needed. The field is collectCycle and the unit is hours.

Gate.io

def _gateio_funding_intervals():
    """Gate.io exposes funding_interval in SECONDS via /futures/usdt/contracts."""
    r = requests.get("https://api.gateio.ws/api/v4/futures/usdt/contracts", timeout=15)
    out = {}
    for c in r.json():
        seconds = int(c.get("funding_interval", 28800))  # default 8h = 28800s
        out[c["name"]] = max(1, seconds // 3600)
    return out

Note the unit: seconds. Divide by 3600.

OKX

def _okx_funding_intervals_from_response(funding_rate_response):
    """OKX doesn't expose the interval directly. Compute it from
    nextFundingTime - fundingTime in the funding-rate response."""
    next_t = int(funding_rate_response.get("nextFundingTime", 0)) // 1000
    prev_t = int(funding_rate_response.get("fundingTime", 0)) // 1000
    if next_t and prev_t and next_t > prev_t:
        return max(1, round((next_t - prev_t) / 3600))
    return 8

OKX is the trickiest. They don't expose the interval as a field — you compute it from the time difference between consecutive settlements.

Hyperliquid and dYdX v4

HYPERLIQUID_INTERVAL = 1   # always 1h
DYDX_INTERVAL = 1          # always 1h

These two venues have a single funding interval across their entire universe. No lookup needed.

The corrected annualization

Once you have the per-symbol interval, the annualization is:

def annualize(funding_rate, interval_hours):
    if interval_hours <= 0:
        return 0.0
    periods_per_year = (24 / interval_hours) * 365
    return funding_rate * periods_per_year * 100  # in %

For an 8h symbol, this gives funding_rate * 1095 * 100.
For a 4h symbol: funding_rate * 2190 * 100.
For a 1h symbol: funding_rate * 8760 * 100.
For a 24h symbol: funding_rate * 365 * 100.

That's it. Five lines of code, applied per symbol with the correct interval, and your scanner is no longer lying to you.

What I see in the wild

I built Funding Finder partly because none of the public alternatives I tried got this right. The free n8n templates assume 8h. The popular GitHub repos assume 8h. Even some commercial scanners I tried showed obvious signs of this bug — claiming 200% APY on a 1h-funding Hyperliquid perp where the actual rate was modest.

Coinglass gets it right (they're a serious commercial product). Coinalyze is BTC-only so it doesn't matter. Most everything else gets it wrong.

If you maintain a public crypto data scraper or scanner, please fix this. The fix is small and the impact on user trust is significant.

Sample broken code from a popular GitHub repo (anonymized)

# Found in a public repo with 800+ stars
def get_funding_apy(rate):
    return rate * 1095 * 100  # 3 settlements per day * 365 days

Not naming the repo, but I've found this exact pattern in at least 5 popular crypto scrapers. If you wrote one of them, you know who you are. The fix is 20 lines.

The OSS data layer that gets it right

I extracted the data plumbing from Funding Finder into an MIT-licensed Python package called funding-collector that handles the per-symbol funding interval correctly across 8 exchanges (Binance, Bybit, OKX, Bitget, MEXC, Hyperliquid, Gate.io, dYdX v4). 700 lines of Python, no async, no dependencies beyond requests.

pip install funding-collector

Or just copy the relevant _<exchange>_funding_intervals() function from this post into your existing scraper. The fix takes 20 minutes.

— Clément

Migrating from Coinglass to Funding Finder: a step-by-step walkthrough for funding-rate arbitrage traders

FoxyyyBusiness — Fri, 10 Apr 2026 10:35:20 +0000

This post is for the specific subset of Coinglass users who use the platform mostly for cross-exchange funding-rate arbitrage data and have wondered if there's a cheaper, more focused alternative. There is. I built it. This is a 10-minute migration guide.

If you use Coinglass for liquidations, ETF flows, on-chain data, options flow, or the broader derivatives surface, this post is not for you and you should stay on Coinglass. It's a great product for that breadth.

TL;DR

	Before (Coinglass Hobbyist)	After (Funding Finder Trader)
Price	$29/month	€5/month
Rate limit	30 req/min	600 req/min
Exchanges	~30	8
Funding-rate history	180 days	30 days (free tier 24h)
API key required	Yes	Optional (free tier no key needed)
Cross-exchange arb endpoint	No native	Yes, ranked + filtered
Open source data layer	No	Yes (MIT)

The math: you save $24/month if you only use the funding-rate features. The trade-off: smaller exchange coverage, less history.

Step 1: Audit your current Coinglass usage

Before you migrate, run through your actual usage of Coinglass over the last 30 days. Be honest. Most users overestimate what they actually use.

Ask yourself:

What endpoints am I calling? If your API logs show 90%+ of calls hit the funding-rate endpoints, the migration math is straightforward.
Which exchanges do I actually need? Coinglass covers ~30 venues but most users only consume data from the top 5-8.
How much historical data do I actually use? If you mostly look at the last week, the 30-day history of the Trader tier is plenty. If you regularly query 90+ days back, you'll need the Pro tier or stay on Coinglass.
Do I use any non-funding endpoint? Liquidations, OI, ETF flows, etc. If yes, stay on Coinglass.

Run this audit honestly. About 60% of "Coinglass for funding-arb" users I've talked to discover they only use 5-10% of what they pay for.

Step 2: Try the Funding Finder free tier

Funding Finder has a no-signup free tier that covers 95% of the data you'd get from a paid Coinglass plan, with one critical caveat: history is capped at 24 hours instead of 180 days.

Try it:

# Current funding rates across all 8 exchanges
curl 'https://foxyyy.com/api/funding/current' | jq '.count, .rows[0]'

# Cross-exchange arbitrage opportunities, sorted by annualized yield
curl 'https://foxyyy.com/api/funding/arb?min_yield=10&min_volume=10000000&limit=10' \
  | jq '.opportunities[] | {base, long_exchange, short_exchange, annualized_yield_pct}'

# History for BTC (24h on free tier)
curl 'https://foxyyy.com/api/funding/history/BTC?hours=24' | jq '.count'

Run those three commands. If the data shape and content match what you need, the migration is feasible.

Step 3: Map your Coinglass API calls to Funding Finder equivalents

Here's the rough mapping for the funding-rate-specific endpoints:

Coinglass	Funding Finder
`GET /api/futures/fundingRate/v2/list`	`GET /api/funding/current`
`GET /api/futures/fundingRate/ohlc-history`	`GET /api/funding/history/<base>?hours=N`
`GET /api/futures/fundingRate/exchange-list`	`GET /api/funding/by_exchange/<ex>`
`GET /api/futures/fundingRate/arbitrage-list`	`GET /api/funding/arb`
(no equivalent)	`GET /api/funding/extremes?n=20`
(no equivalent)	`GET /api/summary` (sentiment + top arb in one call)

The response shapes are different, of course, so you'll need to update your client code. The biggest difference: Funding Finder normalizes everything to a single dict shape regardless of which exchange the data came from, which is one less thing for you to handle.

A typical Coinglass response loop:

# Before (Coinglass)
import coinglass  # hypothetical client
data = coinglass.fundingRate.v2list()
for item in data:
    if item['exchange'] == 'Binance':
        rate = item['fundingRate']  # already a percent? or decimal? check docs
    elif item['exchange'] == 'Bybit':
        rate = item['fundingRate']  # different scale, normalize manually
    ...

After:

# After (Funding Finder)
import requests
data = requests.get("https://foxyyy.com/api/funding/current").json()
for r in data["rows"]:
    rate = r["funding_rate"]              # always decimal, always per-period
    pct = r["funding_rate_pct"]           # already converted to %
    apy = r["annualized_pct"]             # already correctly annualized per-symbol
    interval = r["funding_interval_hours"] # always present, always correct

The Funding Finder schema does the unit conversion and normalization for you, including the per-symbol funding interval (which most other tools get wrong).

Step 4: Update your alerting

If you use Coinglass alerts, you'll need to migrate them to Funding Finder alerts. The endpoints are documented at /docs#alerts.

Sample alert creation:

# Get a paid tier API key first (Trader €5/mo)
curl -X POST 'https://foxyyy.com/api/alerts/create' \
  -H "X-API-Key: $YOUR_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "base": "BTC",
    "min_yield_pct": 100,
    "min_volume_usd": 5000000,
    "telegram_chat_id": "12345",
    "cooldown_seconds": 3600
  }'

The alert worker scans every 60 seconds and sends you a Telegram message when an opportunity matches. Cooldown prevents spam.

Step 5: Run both in parallel for one week

This is the part most people skip and then regret. Don't cancel Coinglass yet. Run both APIs in parallel for one week, log every funding-rate query you make to both, and compare the results. You're looking for:

Coverage gaps: any symbol you queried on Coinglass that's not in Funding Finder
Numerical discrepancies: same symbol, different funding rate? Investigate which one is right (usually the issue is that Coinglass shows the predicted next rate while Funding Finder shows the latest published rate)
Latency differences: how fresh is the data on each side

After a week, you'll have a clear answer to "is this migration worth it for my workflow". If the answer is yes, cancel Coinglass and pocket the $24/month difference. If the answer is no, you've lost €5 and gained the data you needed to make the decision.

Step 6: Self-host the data layer (optional)

If you really care about cost and you're a developer, you can skip the hosted Funding Finder entirely and run the open-source data collector on your own VPS:

git clone https://github.com/clementslowik/funding-collector
cd funding-collector
pip install -e .

# One-shot collection from all 8 exchanges
funding-collector --exchanges binance,bybit,okx,bitget,mexc,hyperliquid,gateio,dydx

# Or run as a daemon
funding-collector --loop 300

That gives you the same data layer that powers the hosted service, MIT-licensed, on your own infrastructure. The hosted service then becomes optional — you'd only pay if you want the API/dashboard/alerts wrapper without the operational overhead.

The OSS package is ~700 lines of Python. You can read the entire codebase in 30 minutes. There's no magic, no plugin system, no async runtime. Just seven fetch_* functions and one SQLite schema.

What you give up by migrating

Honest disclosure of the trade-offs:

Smaller exchange coverage. 8 vs ~30. If you trade alts on Bitfinex, BingX, Phemex, etc., they're not in Funding Finder yet. Open a PR if you want them faster.
Less historical data on the entry tier. 30 days vs 180 days. Pro tier (€15/mo) gets 12 months but it's still less than Coinglass's higher tiers offer.
No liquidations / ETF / on-chain. Funding Finder is funding-rate focused. If you use Coinglass for the broader derivatives surface, stay on Coinglass.
Newer product. Funding Finder is months old, not years. The track record is shorter. The road map is clearer than the path actually taken.

What you gain

6x cheaper entry tier. €5 vs $29.
20x rate limit. 600 req/min vs 30.
No signup for casual use. Free tier needs no account, no email, no API key.
Slippage-aware net APY built into the arbitrage endpoint. Coinglass shows you gross spreads; Funding Finder also computes the net yield after estimated slippage and fees for a given notional size.
Open-source self-host option. Run the data layer on your own VPS for free if you want.
A focused, simple API surface instead of the broad surface you're not using.

Final thought

Migrating tools is annoying. The cost of the migration is real and the benefit is incremental. For Funding Finder vs Coinglass, the migration is worth it if and only if you're a funding-rate-focused user who finds the $29/month painful. For everyone else, stay on Coinglass.

I built Funding Finder because I am that specific user. If you're reading this and recognizing yourself, the free tier is at https://foxyyy.com/. Take 10 minutes, run the three sample API calls, and decide for yourself.

Comparison page (more detail): https://foxyyy.com/vs/coinglass

API docs: https://foxyyy.com/docs

OSS data collector: github.com/clementslowik/funding-collector (MIT license)

— Clément

Seven crypto exchanges, one normalized schema, ~700 lines of Python

FoxyyyBusiness — Fri, 10 Apr 2026 10:35:14 +0000

This is a follow-up to my previous post on building a funding-rate arbitrage scanner. That post was about the product — what it does, the three non-obvious gotchas, and why I built it. This one is about the plumbing: how seven different exchange APIs handle the same data and what it took to unify them.

If you've ever thought "I'll just call the public APIs and join the data, how hard can it be" — this post is for you.

The dataset I wanted

For each USDT-margined perpetual on each major venue, I needed:

Current funding rate (per period, decimal — e.g. 0.0001 = 0.01%)
Funding interval in hours (8h, 4h, 1h depending on the venue and the symbol)
Mark price (for sizing calculations)
24h volume in USD (for liquidity filtering — without this, the scanner is useless)
Next funding time (UNIX seconds — for "this opportunity expires in X minutes" UI)

Sounds simple. It's not. Each exchange returns a subset of this in a different shape, and you usually need at least two API calls per exchange to assemble the full record. Here's how each one works.

Binance

Strategy: two bulk calls.

GET https://fapi.binance.com/fapi/v1/premiumIndex
# Returns ALL symbols with: lastFundingRate, markPrice, nextFundingTime
# One call, ~670 USDT-M symbols, instant.

GET https://fapi.binance.com/fapi/v1/ticker/24hr
# Returns ALL symbols with: quoteVolume (24h USDT volume)
# One call, same coverage, instant.

GET https://fapi.binance.com/fapi/v1/fundingInfo
# Returns the per-symbol fundingIntervalHours, but ONLY for symbols
# whose interval is non-default (4h, 1h). Default 8h symbols are omitted.
# Cache once, refresh weekly.

Binance is the cleanest. The funding interval endpoint returning only non-default symbols is mildly annoying (you have to assume 8h if a symbol is missing) but that's a minor wart.

Bybit

Strategy: bulk tickers + paginated instruments-info.

GET https://api.bybit.com/v5/market/tickers?category=linear
# Returns ALL linear perps with: fundingRate, markPrice, turnover24h (USD), nextFundingTime
# One call, ~544 symbols.

GET https://api.bybit.com/v5/market/instruments-info?category=linear&limit=1000&cursor=...
# Returns funding interval in MINUTES (not hours, not seconds). Convert.
# Paginated, but limit=1000 fits everything in 1 call usually.

Bybit is also clean once you know about the unit (minutes for fundingInterval, USD for turnover24h). The pagination cursor is technically required but in practice you fit everything in 1 page.

OKX

Strategy: bulk tickers + per-instrument funding rate (parallelized).

GET https://www.okx.com/api/v5/public/instruments?instType=SWAP
# Returns the list of SWAP instruments. Filter by settleCcy=USDT.
# ~285 USDT-margined SWAPs.

GET https://www.okx.com/api/v5/market/tickers?instType=SWAP
# Returns volume + last price per instrument. One bulk call.

GET https://www.okx.com/api/v5/public/funding-rate?instId=BTC-USDT-SWAP
# Returns funding rate, fundingTime, nextFundingTime for ONE instrument.
# Yes, one. Per. Call. There is no bulk endpoint for current funding rate at OKX.
# Public rate limit: ~20 req/2s.

This is where it gets ugly. OKX has the most awkward API of the major venues. To get current funding rates for 285 symbols you have to make 285 sequential calls (or 8 parallel workers respecting the rate limit). 285 calls × ~0.3s each ≈ 85 seconds sequential, 8 seconds parallelized.

The funding interval is computed from fundingTime - prevFundingTime because OKX doesn't expose it as a field. That works as long as both fields are present, which they are 99.9% of the time.

from concurrent.futures import ThreadPoolExecutor, as_completed

session = requests.Session()
with ThreadPoolExecutor(max_workers=8) as ex:
    futures = [ex.submit(_one, inst) for inst in usdt_swaps]
    for f in as_completed(futures):
        ...

8 workers stays comfortably under the 10 req/s limit. 0 failures in production for the past day.

Bitget

Strategy: two bulk calls. The cleanest of all.

GET https://api.bitget.com/api/v2/mix/market/tickers?productType=usdt-futures
# Returns ALL contracts: fundingRate, markPrice, usdtVolume, holdingAmount
# One call, ~537 symbols.

GET https://api.bitget.com/api/v2/mix/market/current-fund-rate?productType=usdt-futures
# Returns fundingRateInterval (hours, integer) per symbol.
# One call.

Bitget gets a gold star. Two calls, both bulk, fields named clearly, units obvious. If only every exchange were like this.

MEXC

Strategy: two bulk calls, parallel-friendly.

GET https://contract.mexc.com/api/v1/contract/funding_rate
# Returns ALL symbols with: fundingRate, collectCycle (hours), nextSettleTime
# One call, ~762 symbols.

GET https://contract.mexc.com/api/v1/contract/ticker
# Returns ALL symbols with: fairPrice, amount24 (USDT volume)
# One call.

MEXC's collectCycle is in hours (clean) and they expose every field on bulk endpoints. Symbol format is BTC_USDT instead of BTCUSDT, which requires a small normalization step. Otherwise, also a gold star.

Gate.io

Strategy: two bulk calls + an in-delisting filter.

GET https://api.gateio.ws/api/v4/futures/usdt/contracts
# Returns funding_interval (in SECONDS, divide by 3600), in_delisting flag, name.
# One call, ~642 symbols.

GET https://api.gateio.ws/api/v4/futures/usdt/tickers
# Returns funding_rate, mark_price, volume_24h_quote (USDT volume), contract.
# One call.

Gate.io is fine but has the most variety of unit conventions in a single response: funding_interval is in seconds, volume_24h_quote is in USD, funding_rate is decimal. The in_delisting flag is critical — without it you'll see violently spiking funding rates on coins that are about to disappear, which look like 5000% APY opportunities until you realize you can't trade them.

Hyperliquid

Strategy: ONE bulk POST call. Yes, POST, not GET.

POST https://api.hyperliquid.xyz/info
Content-Type: application/json
{"type": "metaAndAssetCtxs"}

Returns a 2-element array:

[0].universe — list of perp assets with their name (just the base, e.g. BTC, no quote suffix)
[1] — parallel array of contexts with funding, markPx, dayNtlVlm (USD volume)

Single call, 229 symbols, instant. Funding interval is hardcoded 1h (Hyperliquid's entire venue is 1-hour funding).

The catch: it's a JSON-RPC-ish POST API with parallel arrays as the response shape. If you're used to REST GET endpoints, the first time you see this you'll waste 10 minutes wondering why your params={} doesn't work. POST + JSON body, that's the trick.

The unified output

After all that, every exchange's collector function returns the same dict shape:

{
    "exchange": "binance",
    "symbol": "BTCUSDT",            # normalized to <BASE>USDT
    "base": "BTC",
    "funding_rate": 0.00004,
    "funding_interval_hours": 8,
    "next_funding_time": 1775606400,
    "mark_price": 65000.0,
    "volume_24h_usd": 1234567.0,
    "fetched_at": 1775597628,
}

These get inserted via INSERT OR REPLACE into the single SQLite table. The composite primary key (exchange, symbol, fetched_at) means every collector cycle is preserved as history.

7 exchanges, 3700+ symbols, ~12 seconds total per cycle. Most of that is the OKX parallelized fetch (8s) — Binance, Bybit, Bitget, MEXC, Gate.io are sub-second each, Hyperliquid is sub-second, and they all run in series (could parallelize them too, easy win).

What I learned

There is no industry standard for funding-rate data, even for the most-traded instrument class in crypto. Each exchange invents its own field names, units, endpoint shapes, and pagination conventions.
The "single bulk call returning everything" pattern is rare. Most exchanges require 2-3 calls to assemble the full record (rate + volume + interval). OKX requires N+2 calls.
Units matter more than you think. Hours, minutes, seconds, milliseconds, decimals, percentages — every exchange picks at least one unit that surprises you.
in_delisting flags exist on some venues and not others. Without them, you'll publish fake opportunities.
The 1000-multiplier coins (1000PEPE, 1000SHIB, 1000XEC) are a nightmare because their cross-exchange equivalence is non-trivial. I filter them out for v0.

The library is on GitHub at <TBD-after-push> under MIT. It's ~700 lines of Python, no async, no clever metaprogramming, no plugin system. Just seven fetch_* functions and one SQLite schema.

If you want to add an 8th exchange, the contract is documented in CONTRIBUTING.md. The first PR I'd love to merge is dYdX v4 — their REST API is cleaner than most CEXes and I just haven't written it yet.

Live scanner using this library: https://foxyyy.com/

API docs: https://foxyyy.com/docs

I built a free 7-exchange funding-rate arbitrage scanner because I refused to pay $29/month for one

FoxyyyBusiness — Fri, 10 Apr 2026 10:29:03 +0000

TL;DR

I built Funding Finder, a free cross-exchange perpetual funding-rate arbitrage scanner. It polls Binance, Bybit, OKX, Bitget, MEXC, Hyperliquid, and Gate.io every 5 minutes — about 3700 USDT-margined perpetuals — ranks every base coin by the spread between its cheapest long leg and most expensive short leg, annualizes correctly per-symbol, and filters out illiquid noise.

Free web view, free JSON API, no signup. The OSS data collector is on GitHub under MIT.

This post is about the three non-obvious things most existing tools get wrong and how I handled each one. If you trade funding-rate arbitrage even casually, two of them have probably been silently distorting your scanner output.

Why I built it

I trade a small funding-arb book on the side. The data ergonomics for this strategy are surprisingly bad.

Coinglass has the best UI but the entry API plan starts at $29/month with 30 req/min and a 180-day history cap.
CoinAPI is commercial and pitched at institutions.
Coinalyze is free but BTC-only.
Each exchange's native API is free, but you have to scrape, normalize symbols, and reconcile funding intervals per venue. By the time you've done that, you've built half the product.

The strategy itself is dead simple: long the perp on the exchange with the lowest funding rate, short the perp on the exchange with the highest funding rate. Both legs are perp, no spot, beta-neutral. You capture the funding spread until convergence.

What I needed was a no-bullshit table that ranks current cross-exchange spreads by annualized yield, filtered by liquidity, across all the major venues. So I built it.

The architecture (deliberately boring)

collector.py  →  funding.db (SQLite + WAL)  →  api.py (Flask)  →  static/index.html
     ↑
     │
     5-min loop, polls 7 exchange public APIs in parallel

That's it. No Kafka, no Redis, no microservices, no Docker stack. One SQLite file, one Flask process, one HTML file. The whole thing fits in ~700 lines of Python and runs on a $5 VPS.

The schema is one table:

CREATE TABLE funding_rates (
    exchange TEXT NOT NULL,
    symbol TEXT NOT NULL,
    base TEXT NOT NULL,
    funding_rate REAL NOT NULL,
    funding_interval_hours INTEGER NOT NULL DEFAULT 8,
    next_funding_time INTEGER,
    mark_price REAL,
    volume_24h_usd REAL DEFAULT 0,
    fetched_at INTEGER NOT NULL,
    PRIMARY KEY (exchange, symbol, fetched_at)
);

The composite primary key gives you a free historical record. Run the collector in a 5-minute loop and after a week you have a queryable funding-rate history per (exchange, symbol).

Gotcha #1 — funding interval is not always 8 hours

Most tools you find on GitHub assume an 8-hour funding interval everywhere. They compute annualized yield as funding_rate × 3 × 365 (3 funding settlements per day × 365 days).

That's wrong.

Binance has 425 USDT-margined perps on a 4-hour cycle and 4 perps on a 1-hour cycle, in addition to the ~241 standard 8-hour ones. Bybit has 377 on 4-hour and 3 on 1-hour. Bitget and MEXC each have a similar spread. Hyperliquid is entirely on a 1-hour cycle. That's roughly 30% of the available CEX market (and 100% of Hyperliquid) that gets misannualized if you assume 8h.

A 0.05% per-period funding rate is:

≈ 55% APY on an 8h symbol (×3×365)
≈ 109% APY on a 4h symbol (×6×365)
≈ 438% APY on a 1h symbol (×24×365)

If your scanner shows the same annualized number for all of them, your scanner is lying to you.

The fix is to fetch the per-symbol funding interval at startup and cache it:

def _binance_funding_intervals() -> dict[str, int]:
    r = requests.get("https://fapi.binance.com/fapi/v1/fundingInfo", timeout=15)
    return {
        item["symbol"]: int(item.get("fundingIntervalHours", 8))
        for item in r.json()
    }

For Bybit it's /v5/market/instruments-info?category=linear, paginated, with fundingInterval in minutes. Convert to hours, cache, you're done. For Bitget it's in /api/v2/mix/market/current-fund-rate. For MEXC it's collectCycle in the funding-rate response. For Gate.io it's in seconds in /futures/usdt/contracts. For Hyperliquid it's hardcoded to 1 (their entire venue is 1h).

Five exchanges, five subtly different conventions for the same field. Welcome to crypto data plumbing.

This single fix changed the top-10 of my own table substantially. The "best" 8h-symbol opportunity at the top before the fix was actually middling once I corrected the 4h-symbols above it.

Gotcha #2 — the liquidity filter is the actual product

Before the liquidity filter, my scanner found 279 cross-exchange opportunities at any given time. Sounds great.

It wasn't. The top 10 were a parade of:

Coins about to be delisted (one exchange's funding swings violently as market makers hedge their unwind)
New listings with thin order books on one of the two legs
Tokens with $40k of daily volume — your $5k position would move the mark price by 2% on entry alone

Adding min_volume_24h_usd as a both-legs filter brought 279 → 51 at $5M, → 6 at $50M. The 6 at $50M+ are the actually-tradeable ones. Everything else is bait.

Code is trivial:

liquid = [g for g in group if (g.get("volume_24h_usd") or 0) >= min_volume]
if len(liquid) < 2:
    continue

But the realization that the scanner is only as good as the liquidity floor it imposes is the part nobody seems to talk about. It's not a feature of "advanced" scanners, it's the default that should ship.

Gotcha #3 — symbol normalization matters more than you think

Each exchange has its own naming convention. Binance and Bybit use BTCUSDT. OKX uses BTC-USDT-SWAP. Bitget uses BTCUSDT. MEXC uses BTC_USDT. Gate.io uses BTC_USDT. Hyperliquid uses just BTC (no quote suffix because everything is USD-margined intrinsically).

If you join naively, you'll miss half your cross-exchange opportunities. Worse: if you don't know that Binance's 1000PEPEUSDT is the same coin as MEXC's PEPE_USDT (different multiplier), you'll compute a "spread" that's completely fake.

The simple normalization rules for the 90% case:

BTCUSDT → base BTC
BTC-USDT-SWAP → strip -USDT-SWAP, base BTC
BTC_USDT → strip _USDT, base BTC
BTC (Hyperliquid) → base BTC, append USDT for the joined symbol

For the 10% edge cases (1000-multiplier coins, 10000-multiplier coins, exotic pairs), you either build a manual mapping or filter them out. I filter them out for v0 — better to under-report than to publish fake spreads.

def _base_from(sym: str, ex: str) -> str | None:
    if ex == "okx" and sym.endswith("-USDT-SWAP"):
        return sym.removesuffix("-USDT-SWAP")
    if ex in ("mexc", "gateio") and sym.endswith("_USDT"):
        return sym[:-5]
    if sym.endswith("USDT"):
        return sym[:-4]
    return sym  # Hyperliquid: name is already the base

What's next

dYdX v4 and Coinbase Derivatives to round out the universe of major venues
Persistent history endpoint is already live (/api/funding/history/<base>?hours=720) — the rolling collection populates SQLite, the endpoint just exposes it
Telegram alert bot, free, when an opportunity above a user-defined yield + liquidity floor appears
API key system with a paid tier under $10/month for full history (12 months+) and higher rate limits
Slippage estimation using order book depth, so the displayed APY accounts for the entry/exit cost on each leg

Source for the OSS collector + schema is on GitHub at <TBD-after-push> under MIT. The API/dashboard layer stays as a hosted service.

Try it: https://foxyyy.com/

API docs: https://foxyyy.com/docs

Tell me what's broken. Especially if you trade this strategy live — I want to hear about every gotcha that bit you, because the difference between a paper backtest and a real position is all in the details (settlement timing, mark-price gaps at funding-time, withdraw delays, leg correlation breakdown). I'll write a follow-up post on that once I've burned myself a few times.

Built solo. No funding round, no marketing budget, no enterprise sales team. Just one developer who got tired of paying for data that should be in the public domain anyway.

5 systemd units for a Python web app, complete and copy-pasteable. No Docker.

FoxyyyBusiness — Fri, 10 Apr 2026 10:28:59 +0000

This post is a practical reference for the dev who's tired of Dockerfile + docker-compose.yml + nginx config + Watchtower for a personal project. Everything below works on a stock Ubuntu/Debian VPS with no extra tooling beyond python3 and pip.

I run Funding Finder on this exact setup: 5 systemd services, 1 Python interpreter, ~70 MB resident memory total, $5/month VPS. Up for over 24 hours with zero issues at the time of writing.

The 5 unit files are: API server, background collector loop, healthcheck monitor, alerts worker, mission supervision dashboard. They're all independent processes managed by systemd's Restart=always, log to disk, survive reboots, and start automatically on boot.

Copy-paste each into /etc/systemd/system/<name>.service and run systemctl enable --now <name> to activate.

Unit 1 — Flask API server

[Unit]
Description=Funding Finder API server
After=network.target

[Service]
Type=simple
WorkingDirectory=/root/project_30d/artifacts/funding_finder
ExecStart=/usr/bin/python3 /root/project_30d/artifacts/funding_finder/api.py
Restart=always
RestartSec=5
StandardOutput=append:/root/project_30d/artifacts/funding_finder/data/api.log
StandardError=append:/root/project_30d/artifacts/funding_finder/data/api.log
Environment=PORT=8083

[Install]
WantedBy=multi-user.target

The Flask dev server is fine for personal projects up to ~500 req/sec on a single core. If you need more, swap ExecStart for gunicorn -w 4 -b 0.0.0.0:8083 api:app. Same unit file, one line different.

Unit 2 — Background data collector loop

[Unit]
Description=Funding Finder data collector (5-min loop)
After=network.target

[Service]
Type=simple
WorkingDirectory=/root/project_30d/artifacts/funding_finder
ExecStart=/usr/bin/python3 /root/project_30d/artifacts/funding_finder/collector.py --exchanges binance,bybit,okx,bitget,mexc,hyperliquid,gateio,dydx --loop 300
Restart=always
RestartSec=10
StandardOutput=append:/root/project_30d/artifacts/funding_finder/data/collector.log
StandardError=append:/root/project_30d/artifacts/funding_finder/data/collector.log

[Install]
WantedBy=multi-user.target

The collector itself runs while True: collect_all(); time.sleep(300). systemd's Restart=always handles process crashes — if Python segfaults or hits an unhandled exception that escapes the loop, systemd brings it back in 10 seconds.

For a slower cycle (say, 10 minutes), change --loop 300 to --loop 600 and systemctl daemon-reload && systemctl restart funding-finder-collector. No code change needed.

Unit 3 — Healthcheck monitor with Telegram alerts

[Unit]
Description=Funding Finder healthcheck monitor (Telegram alerts)
After=network.target funding-finder-api.service
Wants=funding-finder-api.service

[Service]
Type=simple
WorkingDirectory=/root/project_30d/artifacts/funding_finder
ExecStart=/usr/bin/python3 /root/project_30d/artifacts/funding_finder/monitor.py --interval 600 --alert-after 2
Restart=always
RestartSec=30
StandardOutput=append:/root/project_30d/artifacts/funding_finder/data/monitor.log
StandardError=append:/root/project_30d/artifacts/funding_finder/data/monitor.log

[Install]
WantedBy=multi-user.target

The Wants= directive means: if the API service is stopped, this monitor will be too (but won't fail). The After= directive ensures the monitor starts after the API on boot, so it doesn't immediately alert about a "missing" API that's still booting.

The monitor itself polls /api/health every 10 minutes and sends a Telegram message after 2 consecutive failures. ~150 lines of Python.

Unit 4 — Alerts worker (background dispatch)

[Unit]
Description=Funding Finder alerts worker (Telegram dispatch)
After=network.target funding-finder-api.service
Wants=funding-finder-api.service

[Service]
Type=simple
WorkingDirectory=/root/project_30d/artifacts/funding_finder
ExecStart=/usr/bin/python3 /root/project_30d/artifacts/funding_finder/alerts_worker.py --interval 60
Restart=always
RestartSec=15
StandardOutput=append:/root/project_30d/artifacts/funding_finder/data/alerts.log
StandardError=append:/root/project_30d/artifacts/funding_finder/data/alerts.log

[Install]
WantedBy=multi-user.target

This is the user-facing "alerts" feature that the paid tier uses. 60-second polling cycle, scans the database for active alerts, sends matching Telegram messages with cooldown enforcement. ~200 lines of Python.

I wrote a separate post on the architecture of this worker — short version, you don't need a queue or websockets at this scale.

Unit 5 — Mission supervision dashboard

[Unit]
Description=Mission 30j supervision dashboard
After=network.target

[Service]
Type=simple
WorkingDirectory=/root/project_30d
ExecStart=/usr/bin/python3 /root/project_30d/dashboard/backend.py
Restart=always
RestartSec=5
StandardOutput=append:/root/project_30d/journal/backend.log
StandardError=append:/root/project_30d/journal/backend.log
Environment=PORT=8082

[Install]
WantedBy=multi-user.target

A second Flask service for a different concern (mission supervision dashboard). Same template, different working directory and port.

How to deploy all 5 in one shot

Save the 5 files above into /etc/systemd/system/, then:

sudo systemctl daemon-reload
sudo systemctl enable --now funding-finder-api
sudo systemctl enable --now funding-finder-collector
sudo systemctl enable --now funding-finder-monitor
sudo systemctl enable --now funding-finder-alerts
sudo systemctl enable --now project30d-dashboard

Five commands. Done. All five services are running, will restart on crash, will start on boot, and are logging to files you can tail -f.

To check status:

systemctl is-active funding-finder-{api,collector,monitor,alerts} project30d-dashboard

To restart everything (e.g. after a code change):

sudo systemctl restart funding-finder-{api,collector,monitor,alerts}

To stop everything (e.g. for maintenance):

sudo systemctl stop funding-finder-{api,collector,monitor,alerts}

What you DON'T need

No Dockerfile — your code runs in the host Python, no isolation layer
No docker-compose.yml — systemd is the orchestrator
No nginx in front — Flask listens on the public port directly (or use ufw to control which IPs can connect)
No process manager (supervisor, pm2, etc) — systemd is the process manager
No log shipper (filebeat, fluentd, etc) — tail is enough at small scale
No image registry — there are no images
No CI/CD pipeline — git pull && systemctl restart is your deploy
No staging environment — fix it in prod, you have an audience of 0 right now
No "production-grade" web server — Flask dev server handles ~500 req/sec on 1 core, plenty for personal projects

When you DO need more

Each of those things makes sense at different scales:

Docker when you need to ship the same app to multiple environments with different OS
nginx when you need TLS termination, rate limiting, or static file caching at the edge
gunicorn when you exceed ~500 req/sec sustained
A real DB when SQLite WAL can't handle the write contention (rarely below 50k writes/sec)
A staging environment when you have paying customers whose downtime would cost real money
A CI pipeline when there's more than one developer

Until each of those triggers fires, the boring stack is the right answer. Stop pre-optimizing for problems you don't have.

A note on `Restart=always`

This is the magic line. Without it, a Python crash means the service stays dead until you SSH in and notice. With it, you get automatic recovery from 95% of failure modes for free. The other 5% (corrupted database, full disk, etc) require you to actually fix the underlying problem, but for "the process died because of an unhandled exception" or "OOM killer reaped it", systemd's restart is enough.

Combined with RestartSec=5 (or 10, or 30 — pick based on the cost of a fast restart loop), you get a deployment that's harder to break than 90% of the Kubernetes setups I've seen.

Try it

If you're running a personal project on a Docker Compose stack right now and feeling the operational weight of it, try this exercise: rewrite ONE of your services as a systemd unit. It's a 1-hour project. You'll either love it or you'll discover you actually need the Docker isolation for some specific reason.

Most of the time, you'll love it.

The full source for the 5 unit files above is in the Funding Finder repo (which is the project they run). Live tool that uses them: https://foxyyy.com/

— Clément

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 https://foxyyy.com/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: https://foxyyy.com/shipped
/now — the cross-exchange funding rate dashboard: https://foxyyy.com/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 https://foxyyy.com/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.