DEV Community: tiancaijb

I built 43 sites and made $0. Now I'm trying the opposite approach.

tiancaijb — Thu, 23 Jul 2026 03:31:47 +0000

I built 25 websites to make $1 each. Here's what happened.

TL;DR: 25 single-page cheatsheets. $1 each in crypto. $0 revenue. 15 open PRs. Dev.to drives more traffic than Google. Here's the real math.

1. The idea

Six weeks ago I had a simple theory:

Build single-page cheatsheets for developer tools. Charge $1 in crypto. Let SEO do the work.

The pitch writes itself: "I could Google this for free, but $1 saves me 20 minutes of searching."

It's the classic convenience play. Gumroad proved people pay for well-packaged free information. I just wanted to test if the same works for dev tools, paid in Solana/USDC.

No subscription. No account. No newsletter upsell. One page, one dollar, one payment.

2. What I built

I picked 25 topics across a few categories and built a single-page HTML site for each one:

Crypto dev tools:

Solana CLI cheatsheet
Anchor framework quick reference
Rust CLI essentials
Web3.py snippets
Hardhat command reference

General dev:

Bash one-liners (the ones you actually use)
tmux survival guide
Git undo commands (the most common page)
sed/awk patterns
jq JSON query reference

AI coding agents:

Claude Code quick commands
Cursor shortcuts
Aider workflow reference
Prompt patterns for codegen
Vibe coding anti-patterns

Exchange comparisons:

Binance vs Bybit fee tier comparison
Solana DEX aggregator fees
CEX withdrawal fee reference
Perpetual exchange comparison matrix
KYC-free exchange roundup

Every site is a single index.html — no framework, no build step, no JavaScript bloat. Just a clean reference, a buy button (Solana Pay / USDC address), and a permissive license so people can fork it.

3. The numbers

Metric	Count
Sites live	25
Total build time	~40 hours
Open PRs to Awesome lists	15
Monthly visitors (all sites)	~320
Revenue	$0

That zero stings. I'll be honest — I expected at least a couple of sales by now, even if it was friends throwing a dollar to be nice.

Costs:

Domains: ~$90/yr (25 × $3.99 .xyz domains)
Hosting: $0 (all static, all on Vercel free tier)
Total sunk: ~$90

4. What worked

Three things actually moved the needle:

Dev.to articles. My post about the project itself got more views in 48 hours than all 25 sites combined got in a month. Devs are on dev.to. They search dev.to. Write there.

Great READMEs. The GitHub repos with solid READMEs and screenshots get starred more than the sites get visited. Devs window-shop on GitHub, they don't land on raw HTML pages.

Niche specificity. The most visited page is "Git undo commands" — a topic so specific people search it exactly. Broad topics get buried. Narrow pages get found.

5. What didn't

Awesome list PRs are glacial. 15 open PRs, zero merged. Many have sat for 3+ weeks. The maintainers are volunteers and that's fine, but if your growth strategy depends on landing in awesome-whatever, you need a different timeline expectation.

Crypto-only payment is a filter. Even if someone wants the cheatsheet, sending $1 in Solana requires:

Having an exchange account with SOL in it
Not minding the $0.01+ transaction fee being 1% of the purchase
Bothering to do it

That's three barriers before the first page load. A $1 Stripe link would convert better, but Stripe isn't available in my region.

SEO takes months. I knew this going in, but the reality still hits. 25 sites, 6 weeks, zero organic rankings for anything competitive. The long-tail queries get a trickle, but trickles don't make rent.

6. The real insight

People pay for convenience, not information. But crypto convenience isn't here yet.

The cheatsheet model isn't broken. Gumroad proved it works — for $3-5 PDFs, with Apple Pay. The friction of sending $1 in SOL for a single page is simply higher than the value it returns.

What I'd do differently:

One domain, 25 routes. Don't buy 25 domains. Use cheatsheets.example.com/git-undo. Save $90/yr.
PDF + Gumroad. Let Gumroad handle payment friction. They support crypto too.
B2B over B2D. Devs are cheap. Sell the package of 25 cheatsheets to teams for $20.
Focus on one niche. 25 topics in 5 categories is too spread. Pick one (AI coding agents, crypto dev tools) and own it.

7. Side hustles for devs

This experiment is part of a bigger collection I'm building — a handbook of developer side hustles that actually work (and the ones that don't). Each chapter is one experiment, one landing page, one set of real numbers.

I'm documenting everything transparently because most "side hustle" content is survivorship bias wrapped in an affiliate link. I want the real numbers — success, failure, and the 90% that sits in the messy middle.

Links:

📖 The side hustle handbook (all experiments): side-hustle-handbook.vercel.app
🐙 GitHub repo (code + experiments): github.com/tiancaijb366-pixel/awesome-developer-side-hustles

If you're building something similar or have ideas to test, DM me. I'm always down to trade real numbers for real feedback.

Foundry Fuzz & Invariant Testing: A Practical Cookbook

tiancaijb — Thu, 23 Jul 2026 02:03:08 +0000

Most hacks happen in edge cases the dev never considered. Fuzz testing throws random inputs at your contracts until something breaks — and Foundry makes it fast enough that you run it before every commit. Here are the patterns I actually use.

Getting Started

forge install tiancaijb366-pixel/foundry-security-tests

The companion repo has all these examples runnable. Fork it, run forge test, then rip out the patterns for your own contracts.

1. Basic Fuzzing with `bound` / `vm.assume`

Don't write ten test_RevertIf_* functions. Give the fuzzer a range and let it find the off-by-one.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.20;

import {Test} from "forge-std/Test.sol";
import {Token} from "../src/Token.sol";

contract TokenFuzzTest is Test {
    Token t;

    function setUp() public {
        t = new Token(1_000_000e18);
    }

    function testFuzz_Transfer_Bounds(address sender, address to, uint256 amount) public {
        // `bound` keeps inputs practical
        amount = bound(amount, 1, t.balanceOf(sender));

        // `vm.assume` filters — use it sparingly (slows the fuzzer)
        vm.assume(sender != address(0) && to != address(0) && sender != to);

        vm.prank(sender);
        t.transfer(to, amount);

        assertGe(t.balanceOf(sender), 0);
        assertEq(t.totalSupply(), 1_000_000e18);
    }
}

Key point: bound is faster than vm.assume — it narrows the range instead of discarding inputs. Use assume only for relationships the fuzzer can't infer (e.g., sender != to).

2. Invariant Testing: ERC20 `totalSupply`

Invariant tests check a property holds across random sequences of calls. They catch state-machine bugs that single-function fuzzing misses.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.20;

import {Test} from "forge-std/Test.sol";
import {StdInvariant} from "forge-std/StdInvariant.sol";
import {Token} from "../src/Token.sol";

contract TokenInvariantTest is StdInvariant, Test {
    Token t;

    function setUp() public {
        t = new Token(1_000_000e18);
        targetContract(address(t));
    }

    // This should _always_ be true
    function invariant_totalSupply() public {
        assertEq(t.totalSupply(), 1_000_000e18);
    }
}

Run with:

forge test --match-test invariant -vvv

Add --fuzz-runs 50000 for serious fuzzing. On a commodity laptop that runs in ~30s and catches things you'd never write a unit test for.

Ghost variable pattern: When the invariant involves contract state over time, track a ghost variable in the test contract that mirrors expected state after every handler call.

3. Reentrancy Detection via Fuzz

Foundry rolls back state after every fuzz run, so you can brute-force reentrancy paths without setting up a separate exploit contract for each scenario.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.20;

import {Test} from "forge-std/Test.sol";
import {Vault} from "../src/Vault.sol";

contract ReentrancyFuzzTest is Test {
    Vault v;

    // Track the reentrancy attempt
    bool public attackAttempted;
    uint256 public balanceBefore;

    receive() external payable {
        if (attackAttempted) return; // only re-enter once
        attackAttempted = true;

        // Try to drain before the first call finishes
        v.withdraw(balanceBefore);
    }

    function testFuzz_Reentrancy(uint256 depositAmount) public {
        depositAmount = bound(depositAmount, 1 ether, 100 ether);

        // Fund victim
        v.deposit{value: depositAmount}();
        balanceBefore = depositAmount;

        // Attack from this contract
        attackAttempted = false;
        v.withdraw(depositAmount);

        // If reentrancy worked, vault balance would be < 0
        assertLe(address(v).balance, depositAmount);
    }
}

Why this works: Foundry isolates each fuzz run. You don't need expectRevert — just check the final state. If totalSupply or balance diverged, the fuzzer found a path.

4. Access Control Fuzzing

The most common finding in real audits: an onlyOwner modifier that doesn't cover all state-changing paths. Fuzz every function from every caller.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.20;

import {Test} from "forge-std/Test.sol";
import {Vault} from "../src/Vault.sol";

contract AccessControlFuzzTest is Test {
    Vault v;

    address owner = makeAddr("owner");
    address attacker = makeAddr("attacker");

    function setUp() public {
        vm.prank(owner);
        v = new Vault();

        deal(attacker, 100 ether);
    }

    // Fuzz every state-changing function as an attacker
    function testFuzz_AccessControl_Withdraw(uint256 amount) public {
        vm.assume(amount > 0 && amount <= 100 ether);

        vm.prank(attacker);
        vm.expectRevert(); // should always revert for non-owner
        v.emergencyWithdraw(amount);
    }

    function testFuzz_AccessControl_Pause(bool paused) public {
        vm.prank(attacker);
        vm.expectRevert();
        v.setPaused(paused);
    }

    function testFuzz_AccessControl_Mint(uint256 amount) public {
        amount = bound(amount, 0, 1_000_000e18);

        vm.prank(attacker);
        vm.expectRevert();
        v.mint(attacker, amount);
    }
}

Pro tip: Build a handler contract that wraps every permissioned function and call it from both privileged and unprivileged addresses in your invariant test suite. One function per access level.

5. Oracle Manipulation Fuzzing

DeFi exploits almost always involve price oracles returning manipulated values. Fuzz the oracle input and check what happens to your core accounting.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.20;

import {Test} from "forge-std/Test.sol";
import {LendingPool} from "../src/LendingPool.sol";
import {MockOracle} from "../src/MockOracle.sol";

contract OracleManipulationFuzzTest is Test {
    LendingPool pool;
    MockOracle oracle;

    address user = makeAddr("user");

    function setUp() public {
        oracle = new MockOracle(1000e8); // ETH/USD = $1000
        pool = new LendingPool(address(oracle));
        deal(user, 100 ether);
    }

    // What happens if the oracle price swings wildly?
    function testFuzz_OracleManipulation(uint256 manipulatedPrice, uint256 collateral) public {
        collateral = bound(collateral, 1 ether, 50 ether);
        manipulatedPrice = bound(manipulatedPrice, 1e8, 100_000e8); // $1 to $100k

        // User deposits collateral
        vm.prank(user);
        pool.deposit{value: collateral}();

        // Oracle is manipulated (flash loan, sandwich, etc.)
        oracle.setPrice(manipulatedPrice);

        // User borrows against inflated collateral — or gets liquidated unfairly
        vm.prank(user);
        pool.borrow();

        // Check: can the pool cover all deposits?
        assertGe(address(pool).balance, pool.totalDeposits());
    }
}

What this catches: If your borrow() or liquidation math assumes prices stay within 5% of the previous value, the fuzzer will find the exact value that breaks it. Then you add a circuit breaker or TWAP window.

Running the Full Suite

# Standard fuzz (default 256 runs per test)
forge test

# Heavy fuzz (closer to what auditors run)
forge test --fuzz-runs 50000 --ffi

# Invariant tests (sequences of calls)
forge test --match-test invariant --fuzz-runs 50000

On CI, run the light suite on every push and the heavy suite nightly.

Useful? Check out these resources:

Foundry Cheatsheet — every forge command, cheatcode, and flag I always forget
Contract Audit Checklist — what to check before any deployment
Solidity Snippets — copy-paste patterns for common patterns