2026-09-30 · 5 min read

How a Non-Engineer Built Cardfloor

Somewhere in America right now, someone is deciding whether to sell a Charizard.

They have three tabs open. One is a price site. One is a marketplace listing. One is a spreadsheet where they've typed, by hand, what they paid and roughly what it's worth. They will make a real financial decision, hundreds of dollars and sometimes thousands, the way you'd guess the weight of a suitcase. Cards are assets. The people who hold them run actual portfolios. And they have no real tooling.

My notes from the day I started: "Card collectors run real portfolios with no real tooling: prices in one tab, a spreadsheet in another, deals found by luck." That's the thesis. The rest was building the terminal.

The problem: real money, toy tools

Pokémon, Magic: The Gathering, and Star Wars Unlimited are three games with three price universes. What they share is a collector who behaves like an investor: buying, holding, tracking cost basis, watching for the underpriced listing, deciding when a card has run too far.

Every one of those behaviors has mature tooling in finance: a portfolio tracker, a P&L statement, a screener, a chart with one-day and thirty-day change. In cards you get a patchwork. A pricing site that doesn't know what you own, a marketplace that doesn't know what it's worth, a spreadsheet you maintain by hand until you stop. The information exists. It's scattered across tabs and never joined.

Cardfloor's bet is that if you treat cards as the assets they already are, the right interface is a trading terminal: fast, dense, opinionated.

What I built

• Live market. Top movers, an estimated market cap, search, and a price chart for any card.
• Portfolio. Add what you hold with quantity, cost basis, condition and acquisition date; see realized and unrealized P&L.
• Deal finder. Listings priced below fair value, filterable by discount, condition and game.
• One schema, three games. Pokémon, Magic and Star Wars Unlimited under a single model, so the same portfolio and deal logic work across all of them.

The layer below: the math nobody sees

If you only looked at the screens you'd think Cardfloor was a charting app. The product is underneath, in a few small functions that a year ago I could not have written and would not have known I needed.

A fair value that survives a fake listing. The naive way to price a card is to average the listings. That breaks the moment one person lists a common card for $10,000 to manipulate the comps, or a beat-up copy gets filed as mint. So the estimate throws out the outliers first: it trims anything outside the interquartile range before taking the mean, and falls back to a plain median when there are too few points to trust. It is a boring statistical technique, and it's the difference between a number you can act on and a number you can be played by.

Accounting that sells the right lots. If you bought three copies at three prices and sell one, which one did you sell? Get this wrong and your P&L is fiction. Cardfloor uses first-in, first-out (the oldest lot goes first) and refuses to let you sell more than you hold. That isn't a UI nicety. It's the accounting being correct.

Knowing that a foil is a different card. A holo, a reverse-holo, a first edition and a plain copy of the "same" card can trade at wildly different prices. To a collector they're obviously distinct; to a database they look identical unless you make the distinction explicit. So variant is part of a card's identity, and every data source, three vendors with three vocabularies, gets normalized into one set of terms before anything is compared.

I want to be exact about my role. I didn't hand-write a data pipeline; the queries and the cron jobs are not where my expertise lives. What I brought was the domain judgment, that pump-and-dump listings are a real threat, that FIFO is the honest accounting, that variants are separate assets, and I used AI to turn that judgment into a tested system.

Shipping a platform in a day

The whole thing, five internal packages, three data sources, a Postgres schema, scheduled ingestion jobs, an installable app, landed in one day. Five commits on May 13, including a swap from one database host to another halfway through when the first one fought me.

That isn't a claim about speed. It's the point of building this way, stated plainly. The distance between understanding a market and building the tool for it used to be measured in hiring an engineer, writing a spec, and waiting a quarter. For a domain I understood, that distance was an afternoon. The bottleneck moved from "can I build it" to "do I know what's worth building," which is the constraint I'd rather be limited by.

The honest gap

Cardfloor is real code doing real math, but it is not yet a fully live market. Some of it runs on seed and synthetic data. The market view can serve a curated set of cards, and the deal feed can generate plausible listings when the marketplace credentials aren't wired in. The ingestion pipeline, daily prices from the card APIs and sold comps from eBay, is built, but the live URL doesn't yet run entirely on it.

I'm saying so on purpose. The failure mode I care most about is the one where a polished screen implies a working system that isn't there. A pricing tool that shows made-up prices as if they were real is worse than no tool; it launders a guess into a number people trust. So: the math is tested and trustworthy. The data feeding it is partly demonstration until the pipeline is fully switched on.

Close

The collector with three tabs open isn't missing information. They're missing a place where it's joined up and treated with the seriousness they already bring to it. That's all a terminal is: good tooling, pointed at something people were told was just a hobby.

Cards were assets before I showed up. I just gave them a floor.