DEV Community: tiancaijb

Why I'm preselling my Obsidian AI plugin before writing a line of code

tiancaijb — Sun, 02 Aug 2026 22:40:18 +0000

Disclosure: I used an AI coding agent to collect research and draft this post. I reviewed the final copy before publishing.

I started with an Obsidian plugin idea I thought was obvious. Research killed it. A different one survived, and I'm now preselling it at $19 before writing a single line of code.

Here's the evidence that changed my mind, and the line I've drawn for myself.

The market has a reputation problem, and it's earned

Obsidian has 1,800+ community plugins and no official way to monetize them. So developers roll their own licensing. That's where things go wrong.

A real example, from a forum post about two paid AI plugins:

"Immediately after payment, I encountered a problem with the license key, which I had to request via email. While seeking help, I noticed many similar posts on the forum, indicating this issue has persisted for over a year."

A year. A paying customer waits for a license key by email, while dozens of other users report the same thing.

The CEO of Obsidian, Kepano, confirmed the company won't build an official paid-plugin marketplace: "We are explicitly not doing this." Fair enough. But it means every paid plugin author is building their own licensing, their own delivery, their own support.

Enough of them do it badly that licensing has become a recurring community complaint.

The other failure mode: ship it, abandon it

Plugins get momentum at launch and then stall. It's the most common complaint I found — "I prefer paying to have a well-maintained and feature-rich plugin rather than having to switch between abandoned ones."

That is a useful demand signal, not a guarantee. Some people will pay for maintenance, not just features.

The prices people actually pay

I collected real price points from paid Obsidian plugins:

SystemSculpt: $19/month or $149 lifetime
MeetingMind Pro: $39 lifetime
Typical Gumroad plugin range: $29-149
Top-earning Obsidian plugin on Gumroad: ~$4,200 in month one

Individual developers report $300-4,500/month as a realistic single-person range. So the "indie plugin" game is small but real. My target is at the very bottom of that range.

What I'm building, and how the research shaped it

The idea is a plugin that treats your vault as a body of reasoning, not a folder to clean. It is called Vault Coherence: a semantic audit for contradictions, missing context, conclusions that appear to lack supporting notes, and ideas that have drifted apart. The value is a clear review of what needs attention, not another chat window.

Research changed three decisions:

License delivery must be part of the product. At release, payment should lead to an immediate key, not an email wait. That alone differentiates from the most established competitor.
Local-first by default. Bring your own API key (DeepSeek, OpenAI, or Ollama locally). Obsidian's developer policy requires disclosing outbound requests; we disclose them in settings.
Maintenance is a promise, not a footnote. Public roadmap, twelve months of updates, build-in-public from day one.

Why presell

I've been here before. My previous Obsidian plugin — obsidian-gtd, a task-management tool — hit 500 downloads and made exactly $0. It worked. People downloaded it, some used it daily. Nobody paid. A free plugin quietly teaches people your tool is worth nothing.

So this time the money comes first, or the plugin doesn't get built.

Because opinions are cheap and purchases are not. The Mom Test has a useful rule: talk about people's lives, not your idea; ask about the past, not the future. A landing page where strangers either pay or don't is the most honest interview there is.

The bar is deliberately low: two sales and I build. Four weeks with zero and I switch to the backup idea. Either outcome is data I can act on.

The presale price is $19 for the first 20 buyers (planned final price: $39). Development starts after the second presale, with delivery within two weeks after that milestone. If the second presale does not arrive within four weeks of launch, everyone gets a full refund. You can also request a refund if I miss delivery or the plugin is not right for you.

If this sounds like the tool your vault needs, here's the page. If it doesn't, tell me what you actually use for this — that's also data.

Vault Coherence — $19 presale

If the presale clears that bar, I'll post the build in public here. I plan to start with the licensing system, since that's where everyone else seems to stumble.

I built a dev.to publishing tool for my coding agent. The key problem was the shell, not the code.

tiancaijb — Sun, 02 Aug 2026 15:09:33 +0000

My coding agent runs most of my writing workflow now. Drafts live as markdown files, and publishing them to dev.to was the one manual step left. So I made it a tool the agent can call itself. One 8.9KB extension file. Three actions. Two environment traps that had nothing to do with the code.

This is part of a build-in-public experiment that started in August 2026. I ran 43 sites to almost $0 and ~320 monthly visits before realizing the lesson: dev.to gives more traction in 48 hours than 25 static sites got in a month. Publishing fast and often is the whole game. The publish step has to be cheap.

What you need

A pi coding agent (any agent with an extension system works, the pattern carries over)
~/.pi/agent/extensions/ as the extension directory
A dev.to API key, generated in your dev.to settings

The tool

pi auto-discovers TypeScript files in ~/.pi/agent/extensions/ and loads them with jiti, no build step. An extension is just a factory function:

import { Type } from "typebox";
import { StringEnum } from "@earendil-works/pi-ai";
import type { ExtensionAPI } from "@earendil-works/pi-coding-agent";

export default function (pi: ExtensionAPI) {
  pi.registerTool({
    name: "publish_devto",
    description: "Publish or update markdown drafts to dev.to, or list status.",
    parameters: Type.Object({
      action: StringEnum(["list", "create", "update"]),
      file: Type.Optional(Type.String()),
    }),
    async execute(_toolCallId, params) {
      // ...
    },
  });
}

The tool exposes three actions:

list — show what's in drafts/ and published/
create — read a draft, POST it to dev.to as a draft by default, write back devto_id/devto_url into the frontmatter, move the file to published/
update — PUT changes to an existing article using the stored devto_id

The design choice that matters: the markdown file is the source of truth. Frontmatter holds the title and the dev.to IDs. What you see in the file is what goes to dev.to, minus the bookkeeping keys.

The API key trap

The first version read the key from the shell environment. It worked in my terminal. It failed inside the agent session. The agent is launched by a terminal multiplexer, whose bash panes are non-interactive shells. My .bashrc has this as its sixth line:

[[ $- != *i* ]] && return

That's a common early-exit guard: "if this shell isn't interactive, stop reading." Everything after it — including my export DEVTO_API_KEY=... — never runs in the agent's shell. The key simply wasn't there.

The fix was to stop trusting the environment entirely:

function devtoApiKey(): string | null {
  const fromEnv = process.env.DEVTO_API_KEY;
  if (fromEnv) return fromEnv;
  try {
    return fs.readFileSync(KEY_FILE, "utf8").trim() || null;
  } catch {
    return null;
  }
}

Env var first, then a fallback to ~/.pi/agent/devto.key with chmod 600. The key never lives in code, and the tool works whether or not the shell bothers to load my exports.

Two more traps

401 that wasn't the key. GET /api/articles/me without a ?state= parameter returns 401 even with a valid key. That's the endpoint's behavior, not a credential problem. Use ?state=published or just test with a POST.

The write-back bug. create writes devto_id and devto_url back into the frontmatter of the archived file. My first pass got that bookkeeping wrong. A mock-API end-to-end test caught it before anything touched the real endpoint — worth the ten minutes to set up.

The workflow it enables

The agent now drafts, I review the file, publish_devto create stores it as a dev.to draft, and I hit publish in the browser. One human gate on the final click, everything else scripted.

The project is a public experiment in whether a solo developer can get to $1/day with a small agent budget. The machine that produces the content is also the content. This tool is one more brick, and the whole thing is on GitHub.

One more thing: this is the first extension the agent wrote entirely by itself. I gave the machine an evolution loop — it gathers skills from GitHub, writes its own extensions, and I review plus reload. This tool is the first output of that loop.

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