It’s a specific kind of itch you can’t quite scratch with existing tools. You have ManaBox, which is fantastic for cataloging and managing your collection, but it locks features like multiple binders or deck management behind a paywall. Then you have Archidekt and Moxfield, the current kings of browser-based deck construction, but they feel designed for quick browsing rather than deep, structural editing.
The friction point wasn’t just about price or ads — it was about input.
Every Magic card printing has a set code and a collector number. M15 plus 42. That’s it. If you have a list of cards, you can type those two identifiers into a spreadsheet and populate an entire deck in seconds. Yet almost every modern deck builder forces you to search by name, filter by cost, or drag-and-drop from a visual library. It’s slow. It breaks my flow.
So I decided to build my own. Not because I hate the existing options, but because I wanted a tool that treated my collection like data first and graphics second. This is also a chance to dip my toes into languages I’ve been meaning to experiment with, creating a side project that my Magic group can actually use without worrying about subscription renewals or ad trackers.
The core premise is simple: spreadsheet-style entry is the fastest way to build a deck.
Most apps assume you are browsing for inspiration. I am often already there in spirit — I know what card I want; I just need to instantiate it. If I have my collection database synced up, entering M15#42 should be as fast as typing a username into a chat window.
I’ve extended this idea further. It’s not just about adding cards; it’s about querying the gap between what I own and what I want to play. The “better” deck-building engine I’m sketching out would work like this:
- Look at my current collection inventory.
- Query against public databases (like Archidekt’s API) for Commander decks that are largely compatible with what I already have.
- Highlight the specific cards I’m missing to complete a new Commander list I haven’t tried yet.
This turns deck building from a creative blank-slate exercise into a logistical puzzle with defined constraints. It’s less “What’s cool?” and more “What can I actually play this weekend based on my current inventory?”
Beyond entry speed, there’s a workflow issue with sideboarding that annoys me in nearly every competitor app.
In Magic Commander (EDH), you don’t just have a mainboard; you have a “maybeboard.” These are cards you’re considering swapping in. In most apps, you deal with these using labels or separate lists. It feels disconnected. I want to be able to say, “Swap this specific card out for that other card,” and have the UI make that transaction obvious and reversible.
It’s not just about toggling visibility. It’s about the action of substitution. If I’m testing a new removal spell, I should be able to drag it onto an existing slot and have the old card move to a “rejected” pile automatically, rather than manually deleting and adding. It sounds minor, but over fifty deck iterations, that friction adds up.
To keep this from becoming another endless prototype, I need a clear feature timeline for the minimum viable product. The goal is to replicate the strengths of both major players while connecting them with the glue they lack.
- Replicate Archidekt’s discovery: fast search, reliable card data, and easy deck sharing.
- Replicate ManaBox’s ownership: accurate tracking of what I physically own, including condition and copy counts if necessary.
- The connective slice: the ability to filter public deck recipes through my personal inventory. If a recipe calls for a pile of cards I don’t own, flag it as “Hard Mode.” If I already own every required card, mark it “Ready to Build” — and if I’m missing only a handful, show exactly which cards I’d need to acquire.
There’s a pragmatic justification here too. I don’t need to run ads. I don’t need to convince users to buy premium features. This tool exists because it solves my problem, and by extension, my friend group’s problem. If Kenney likes it, he uses it. If he doesn’t, he ignores it. There is no churn metric to manage.
This freedom allows me to take risks on UX patterns that commercial apps might avoid. I can prioritize keyboard shortcuts over click-throughs. I can prioritize data density over whitespace. I can build the “sideboard swap” mechanic exactly how I want it without worrying if it’s too complex for a casual user who just wants to copy-paste a deck from Twitter.