I started this project in December 2025. Not because anyone asked. Not because I saw a gap in the market. Because I compose chess problems as a hobby and every tool I tried to export a diagram with either watermarked the output, required an account, or exported at 72 DPI like it was still 2003.
So I built my own. Seven months later: 5 stars on GitHub, 6 forks, a handful of npm downloads, about $13 spent on hosting.
That's the whole story, numbers-wise.
Why I kept going
The tool actually works. That sounds like a low bar, but a lot of side projects don't clear it.
You paste in a FEN string, configure the board however you want — colors, piece set, whether to show coordinates — and export a PNG at up to 1200 DPI with real physical dimensions. You tell it "6cm board at 600 DPI" and it gives you a file you can drop straight into a print layout. No watermark. No account. No ads.
I added cloud sync, batch export (up to 10 positions as a ZIP), a FEN history, a position database search. Probably spent too long on some of that. But the core thing works exactly as I wanted it to.
The bugs that actually taught me something
Safari has a GPU memory limit on canvas elements that Chrome doesn't. If you don't reset canvas.width = 0; canvas.height = 0 after every blob export, iOS will crash — silently, with no useful error. I hit this, spent a while confused about why it only happened on iPhones, then traced it down and fixed it. Now it's a documented invariant in the codebase: you touch the canvas export path, you reset the dimensions after. No exceptions.
The FEN parser has co-located unit tests and a rule: every change requires a new test case. It sounds strict but it's saved me twice.
These are the parts I'm actually proud of.
What I got wrong
I thought if the tool was good, people would find it. That's not how it works.
GitHub has no discovery mechanism. npm sorts by download count — which means new packages are invisible by default. The people who need your tool don't know it exists and aren't searching for it by name.
I also built for a narrow audience without fully accepting what that meant. Chess composers are a small group. Most chess players don't need to export diagrams to print. I knew this going in, but I still somehow expected more traction.
The npm package
A month ago I extracted the rendering core into a separate package: @chessvision-org/chess-vision. Zero dependencies, works in Node.js, Deno, Bun, and the browser. Pure SVG output — no DOM, no canvas.
import { generateDiagram } from '@chessvision-org/chess-vision';
const svg = generateDiagram({
fen: 'rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq e3 0 1',
size: 400,
showCoords: true,
});
The idea was that even if the web app never takes off, the package might be useful to someone building a chess blog or generating diagrams server-side. It's only been on npm a week so I have no idea yet.
Where I'm at
The code is the best it's ever been. The tool does what I wanted it to do. I've learned more about Canvas, Safari memory behavior, Supabase RLS, and FEN parsing edge cases than I ever would have otherwise.
But I haven't figured out how to reach the people who would actually use it. That part is harder than the technical stuff. I'm more comfortable writing a parser than writing a cold message to a chess magazine editor.
I'm going to keep working on it. Just with less time on features and more time actually talking to people.
Repo: github.com/chessvision-org/chess-vision
Tool: chessvision.org
Package: @chessvision-org/chess-vision
If you've been through something similar — built something real, got nowhere with distribution — I'd like to hear what you did.
Top comments (0)