What I've built, and what I post.

Why I built it

Most VGC team-building is repetitive analysis: damage rolls, speed tiers, EV maths, checking your team against the current meta. Players were doing it in spreadsheets or in their heads. I wanted one place that did it for you. Paste a team, get the report.

What it does

• Team report. Paste a Showdown export → instant analysis: damage calcs against the top 30 of the meta, speed tiers, role coverage, and the threats this team is weak to.
• Explore. Browse curated team reports from real tournaments, filterable by regulation, archetype, and Pokémon.
• Compare. Two teams side by side: turn order, common KOs, who wins under Tailwind vs Trick Room.
• Champions. Dedicated section for Pokémon Champions Reg MA, including Mega-form coverage that other tools didn't have when I shipped it.

What's interesting under the hood

• Auto-regulation detection. The site infers which Reg (G / H / I / Champions MA) a team belongs to from the Pokémon used. No manual switching, no wrong analysis.
• Damage calcs in the browser. A port of Showdown's own damage formula runs client-side. No server round-trip per calculation, instant feedback.
• Postgres + full-text search across Pokémon, items, abilities, and tera types. Reports dedupe on a fingerprint of the set so the same team uploaded twice doesn't pollute the explore feed.
• Static where I can be, server-rendered where I have to be. The explore feed and team reports themselves are SSR; static landing pages are pre-rendered.

How it grew

Zero paid marketing. Most of the early traction came from posting my own teams on Reddit. Where most players share a Showdown paste, I'd link a full team report instead, so anyone reading could see the damage maths, speed tiers, and threat coverage I was building around. The reports did the selling; word-of-mouth did the rest. 227 players signed up so far (20 active in the last 30 days, pulled live from Clerk), and the kind of feedback I want: "this saved me an hour of maths before locals."

Inside a team report

The six Pokémon are the easy part. The analysis around them is what I keep coming back to. Below are the sections I lean on when I'm building or matching up.

Why I built it

The best VGC team reports in the world are written in Japanese. They're note.com posts where the player walks through every EV decision, every item choice, and the way the team is meant to win. Machine-translating them in a browser tab loses all of it: kana names mangle, EV blocks get garbled, and the strategic context disappears. I wanted a tool that read the structure of a VGC article, not just the prose.

What it does

• URL or text input. Paste a note.com link or drop the article body in directly.
• Structured extraction. Gemini pulls out each Pokémon's name, item, ability, tera type, EVs, nature, and moveset, instead of giving you a flat translation.
• Strategy notes, kept. The "なぜこの構築" (why this team) section gets translated as English prose so the reasoning carries over.
• Export. Download as Showdown paste so you can drop the team straight into a damage calculator or VGC Team Report.

Why it's a Streamlit app

Streamlit was the right tool for the job: single Python file, hosted free, deploys on push. The whole thing is a thin wrapper around Gemini, with a structured output schema doing the heavy lifting. Bring-your-own-API-key, so it costs me nothing to run.

Where it fits

It feeds VGC Team Report. Translate a Japanese article, paste the resulting Showdown export into the team report site, get the full damage and threat analysis. Two small tools that compose.

Why this exists

Three patterns kept showing up at the trade nights I went to. Vendors losing track of £300 deals because the DM thread had fallen off the top of an Instagram inbox. Traders buying a card they already owned because the binder at home wasn't searchable. People shaking hands on a deal, forgetting what they'd agreed, and apologising later. None of that is a hard problem. It just needed a single place to put it.

What's in it

It splits cleanly between the trader/solo-vendor side and the shop-style operations. The trader-facing pieces:

• My Collection. Every card I own personally, with what I paid, what it's worth now, where I got it, and how long I've held it. Filter by type, favourite, "open to trade." This is the binder, made searchable.
• Portfolio. The net-worth view. 12-month value chart against cost basis, top winners and losers by ROI, allocation by type. Tells me at a glance whether I'm up or down for the year.
• Trade Night Mode. The reason most of this exists. You start a session when you arrive, then everything is one tap: log a trade, add a trader you just met, run a trust check on a handle before you ship anything, do a quick margin calc. Big buttons because you're using it standing up at a table.
• Trades pipeline. Drag-and-drop kanban from enquiry → negotiating → confirmed → shipped → completed. Multi-channel (Instagram, Discord, Whatnot, email).
• Traders, inventory, wishlist, inbox. The shop-side stuff that grew out of the personal stuff. Trust scores, dispute history, KYC flags, market deltas. Honest about which traders to be careful with.

What's interesting under the hood

• No backend. Pure HTML/CSS/JS. State lives in localStorage with a versioned key and a graceful migration path so old saves don't break new schemas.
• One global error guard. If anything throws mid-render, a banner appears with a one-click "Reset Demo". The demo can never paint itself into a corner.
• Hash routing. Each tab is a hash route, so deep links work and back/forward buttons behave naturally.
• SVG charts hand-rolled. No charting library. The Portfolio chart is a single inline SVG with two polylines (value and cost basis), a gradient area fill, and grid lines.
• Mobile-first Trade Night. The action grid collapses 3 → 2 → 2 columns down to phone width. Sidebar tucks behind a hamburger. Tested on an actual iPhone before I called it done.

The Trade Night view in action

Demo to production

The demo runs entirely in the browser. A single folder served with python -m http.server, data in localStorage, no backend. To take it live, drop the folder onto Cloudflare Pages or Netlify for an HTTPS URL in under a minute. There's a config layer that swaps every connector from demo to live the moment a real API key is added: TCGplayer for market pricing, Stripe for payments, Gmail / Discord / Instagram for the inbox, eBay and Shopify for inventory sync. No keys, no calls. Add a key and the same connector starts hitting the real endpoint, with a "LIVE" badge on the card to show you it's no longer mocked.

What it does

• Two draft formats. Snake with automatic turn progression, or auction with live bidding and countdown timers.
• Official pools. VGC Reg G and H, Smogon tiers, and Pokémon Champions Reg M-B / M-C (the 23 M-C species were added the week the regulation dropped).
• Live for everyone in the room. Picks sync over Supabase WebSockets; guests join from a shared link, no registration.
• Auto-pick and wishlists. A priority list drafts for you when the clock runs out, with budget tracking and coverage analysis as you go.
• Player profiles. Career record, titles, nationality and season history on a public page per player.

Status

Live at draftpokemon.com with 1,175 sign-ups and counting. The fix queue is in Notion and the fixes become content.

What's interesting under the hood

• Team showcase. Up to six Pokémon as era-correct sprites (resolved from PokéAPI, labelled by the games' first release) or English TCG and TCG Pocket card printings (resolved from TCGdex). Download as a high-res PNG or share a link that carries the choices in the URL fragment, no database needed.
• Works without a backend. Game reference pages and the Teams editor run with no database; tracking and community boards switch on with Supabase, sign-in with Clerk.
• Guard rails. Provider outages and missing artwork surface in the editor, and incomplete designs can't be exported. A test/live key mismatch fails early with a readable message.

How it's built

• Web first. The Vercel app is the production target; the Capacitor iOS and Android shells wrap a static export of the same UI, so one codebase ships everywhere.
• Row-level security everywhere. Supabase RLS policies are the authorisation layer, with migrations applied in numeric order and documented in the repo.
• Compliance as code. The Online Safety Act assessment, moderation runbook and pre-launch checklist live in docs/ next to the code, with live-verified statuses.
• Built in public. The build log is a running series on Instagram and TikTok; the roadmap and tickets are in Notion.

These are the ones I run on my personal projects. The rest of my routines are work-side and stay off this site.

Scheduled routines

• Weekly lint Weekly
  Runs across my repos every week and surfaces lint and format drift before it stacks up. Cleans the small stuff so it never becomes a half-day chore.
• VGC monthly chaos refresh Monthly
  Refreshes the chaos-stats data feeding VGC Team Report. Pulls the latest Pokémon Showdown usage stats, processes them, and updates the site so every team report stays current with the meta.
• Linear queue drain Recurring
  Drains the VGC Team Report Linear inbox. Triages incoming bug reports, feature requests, and player feedback into the right lanes so nothing gets lost.
• Meeting prep briefing Daily
  Reads my Google Calendar at the start of the day. For every meeting on the agenda it drafts a short brief: what the meeting is about, what I should be prepped for, what I want to say, what to ask. I open the day with the briefs already waiting, not assembled in the five minutes before each call.

Why bother

Each one is a job I'd otherwise put off until Sunday evening. Once it's scheduled, it happens. The hours that used to go on chores now go on the projects on this page.

What this is

VGC is one of the most analytically dense competitive games in existence: damage rolls, EV spreads, speed tiers, and format legality across five regulations. Players normally context-switch between Showdown, Smogon, the damage calculator, and Pikalytics to make a single decision. The MCP server collapses that into a conversational interface inside Claude. Ask "does my Flutter Mane OHKO Incineroar in rain?" or "design a spread for Ogerpon-Hearthflame that survives Urshifu, Flutter Mane, and Chi-Yu" and you get a Showdown-ready paste back with the maths transparent.

What I use it for

Damage and survival maths, in Claude Desktop. It saves me opening Showdown's calc and re-entering the same context every time.

• "Can my Iron Hands survive a +1 Calyrex-Shadow Astral Barrage?"
  Plain question, instant answer with the exact rolls and the EV spread that gets me over the line. The thing I reach for ten times a session.
• "What's the min HP/SpD to live this hit at +1?"
  Tells me the breakpoint and the EV cost. Saves me the spreadsheet.

What else is in there

The full surface covers damage calculations, EV optimisation, team analysis, speed control, meta intelligence, game planning, and format legality across Reg F / G / H / I plus Pokémon Champions Reg MA. I lean hardest on the damage maths layer day-to-day; the rest is in there for when I need it, with tests to back it up.

How rigorous is the maths

The Gen 9 damage formula is implemented to Smogon's full 4096-scale modifier chain. Multipliers are stored as integers (4915 for a 1.2× boost, for example) so the server matches Showdown's calc bit-for-bit, not as a rounded approximation. The test suite pins specific 4096-scale values rather than ranges, with regression tests for real production bugs (like a guard that prevents Prankster Pokémon from being misread as having Fake Out). 1,199 tests passing, 0 failing, 51% line coverage across roughly 18k lines of code.

Architecture

• Python 3.13, FastMCP, async via httpx, validated with Pydantic v2
• Damage engine ported from Showdown's 4096-scale Gen 9 formula, multiplier-by-multiplier
• One calc engine, two format systems (mainline VGC and Pokémon Champions Reg MA), with the regulation auto-detected from team contents
• Pure functions in calc/, side effects only at the boundaries. Cacheable, testable, parallelisable
• Hosted on Render, kept warm by a 14-minute keep-alive ping so the first cold call doesn't time out

See it in use

A real Claude conversation using the server for the damage and survival maths described above: claude.ai/share/747d7985 ↗

Why it's open

I built it for myself first. Once I noticed I was relying on it daily, opening it up made sense. The repo is on GitHub; install instructions are in the README.

Why bother porting it

I'd already built the responder as a Node.js CLI plus a small dashboard. The maths and the prompt were good, but a CLI is unreadable to a non-developer. n8n's canvas is the opposite: every step is a labelled node, every input and output is inspectable, and changing the client config is a single edit on a single node. The port turned my working code into something a future operator could read without me.

What it does, end to end

• Manual Trigger → Sample Review. A 2★ review sits in the workflow as a placeholder. In production this slot is a webhook or a scheduled scraper.
• Client Config (Code). One node holds everything client-specific: name, address, services, voice, the forbid list, the remedy guidance. The workflow becomes generic the moment you edit this one node.
• Build Prompt (Code). Assembles the system prompt from the config and the review, then packages a Gemini request body. Optional fields (legal entity, founded, online offer, contact) render conditionally so a half-filled config still produces a clean prompt.
• Gemini API (HTTP Request). Calls gemini-flash-latest with responseMimeType: application/json. Authenticates via a Header Auth credential I created and bound from the n8n REST API, not by leaking the key into the URL.
• Parse Response (Code). Surfaces real upstream errors (auth failures, safety blocks, no candidates) instead of swallowing them. The first version of this node masked a 403 as "Unknown error [line 11]", which forced the rewrite.
• Switch by classification. Routes to one of four format branches: PRAISE, CONSTRUCTIVE_NEGATIVE, POLICY_VIOLATION, AMBIGUOUS. Each branch builds the payload an owner-approval email would carry: subject, draft, alternative, owner notes, and a deep link.

What's interesting under the hood

• Structured-output JSON, end to end. Gemini is told to return one object with a fixed shape (classification, confidence, reasoning, draft, alternative, owner notes). Parse Response trusts the schema; downstream nodes wire to specific fields rather than blobs of text.
• Self-contained import. The system prompt and the policy taxonomy are inlined into the Code nodes, not pulled from external files. Drop the JSON into any n8n instance and it runs.
• Driven from outside the canvas. Every change in this build was made via n8n's REST API: workflow created with POST /workflows, credential created with POST /credentials and bound to the HTTP node, updates pushed with PUT. Operators see the canvas; an automated agent ships through the API.
• Validation before deploy. Each draft of the workflow JSON went through the n8n-mcp validator (typeVersion checks, expression linting, connection sanity). Cheaper than a failed execution.
• Human-in-the-loop preserved. The workflow stops at "draft for review". The four format branches are the seam where a Gmail → Create Draft node plugs in: the LLM never publishes anything customer-visible, the owner approves before posting.

What it looks like

Rendered from the actual workflow JSON running on my machine: same nodes, same connections, same colour-coding as the canvas in n8n.

The two-track learning

I build these in pairs (a working app and an n8n workflow) because they teach different things. The app shows what is happening line by line. The workflow shows what survives translation; anything resting on a hidden assumption breaks the moment you draw it as nodes. The auth pattern, the error handling, and the way config flows through the prompt all got cleaner in the canvas version because the canvas refused to hide them.

Status

Runs on my own machine, against my own Gemini key. Not deployed publicly: local n8n is a workshop. The original Node.js version is a separate piece in my own folder structure; this entry is specifically about what changed when I moved it to a canvas.

What's interesting under the hood

• One agent per clip. Heavy jobs run as separate Claude Code sessions with pidfiles, a queue and a daily budget, so a bad edit never blocks the next one.
• Approval is the product. Every output is a Telegram card with ✅ / ✏️ / ℹ️ buttons. Nothing posts without a tap.
• Privacy guard rails. Agents are denied Gmail, Calendar and Drive by default; a hook blocks private Notion pages; emails and phone numbers are scrubbed before anything reaches Telegram.
• Instagram Trial Reels. Reels go out as a Trial Reel and a regular Reel at the same minute, because trials reach non-followers.
• Self-healing. A watchdog restarts the gateway and remounts Drive; a GitHub Actions heartbeat pings Telegram if the PC goes quiet.

Tools

• Search. find_nearby_courts, check_availability, find_available_games, compare_prices.
• Planning. search_by_duration, get_weekly_availability, find_cheapest_time, get_peak_hours.
• Habits. Favourite venues with a one-call quick_book_check, and availability alerts for the slots you actually want.

What this is (and what it isn't)

A seven-page brand site I built for Oddono's on my own time, as a customer of theirs. I've got their loyalty card, I'm in the South Kensington shop often, and one evening I looked at their existing site and thought it could be sharper. So I built the version I'd want it to be.

To be clear: this is unsolicited and unaffiliated. I have not spoken to anyone at Oddono's about it. They have not asked for a redesign. Nothing here has been pitched, sent, or shipped to the business. It is me liking a brand enough to design a site for it the way you might cover a song you love. If they ever want to look at it I'd be delighted; until then it stays a sketch in public.

What's there

• Home. Hero, product highlights, calls-to-action.
• About. The family story, the way the gelato is made, the values.
• Shops. Store finder, sortable by distance from the visitor's location.
• Wholesale. For cafés and restaurants who want to stock it, with a real intake form.
• Reviews. Pulled-out testimonials, hand-curated.
• Contact. Straightforward, with the details a customer needs.
• Loyalty. The framework for a future digital stamp card.

What's interesting under the hood

• Store finder without a map library. Just lat/lon distance maths and a sortable list. Faster, simpler, no third-party dependency.
• No build step. Plain HTML/CSS/JS. Deploys in seconds on Vercel.
• Forms are demo-only. Production would wire them to a real backend with proper validation, anti-spam, and email delivery.

A few of the pages

Status

Live and clickable as a personal demo, hosted on a generic Vercel subdomain. It does not sit on any Oddono's domain or under any branding agreement. The form fields don't submit anywhere, the imagery is placeholder, and there is no "production" version because Oddono's hasn't engaged me to build one. If you're from Oddono's and you've stumbled onto this: hello, I'm a fan, this exists with no expectation, take whatever's useful or ignore it entirely.