Custom MTG Proxy Project Checklist: From Theme Idea to Finished Print Files

TLDR: This custom MTG proxy project checklist turns a theme idea into an organized set of finished files. Define one visual rule, freeze the card list, track every asset, build lands and tokens as subsystems, resolve double-faced cards early, and proof at both card and battlefield scale. Do not export the production package until the card list, back mapping, special-card notes, and provider requirements all agree.

A full alternate-art deck is not merely a folder containing 100 attractive images. It is a visual system with dependencies: changing the palette affects the lands, replacing a planeswalker may add an emblem, and revising the back can invalidate an entire export batch. The safest approach is to make each stage produce a clear, approved deliverable before the next begins.

The copyable custom MTG proxy project checklist

Define the use case, theme, visual priorities, approver, deadline, and proof-round limit.
Write a short art-direction brief covering palette, motifs, frame treatment, crop rules, readability, and allowed exceptions.
Create a master card list with stable IDs, quantities, deck roles, special-card flags, and status fields.
Freeze a production version of the list before preparing final files.
Create an asset tracker for art sources, permission or commission notes, attribution requirements, crop versions, layouts, and approvals.
Build a representative test set before laying out the entire deck.
Approve the front-frame system and one master card back.
Mark the project clearly as unofficial and keep that identification consistent.
Treat basic lands and nonbasic lands as coordinated visual groups.
Audit every token, emblem, counter, reminder, and helper card generated or required by the deck.
Map both faces of every double-faced card and document how it will function in hidden zones.
Flag split cards, adventures, battles, sagas, planeswalkers, flip cards, meld cards, and other unusual layouts.
Separate source art, working files, proofs, approved masters, production exports, and archives.
Run a card-size proof for crop, text, contrast, symbols, and edge safety.
Run a battlefield proof for recognition, category separation, and visual cohesion.
Confirm the selected provider’s current dimensions, bleed, color, format, naming, back-mapping, and content requirements.
Build a handoff package containing the frozen list, approved exports, mapping notes, token quantities, contact sheet, and version log.
Archive editable masters and the exact submitted package so replacements can be produced later.

1. Define the project before collecting art

Start with a one-page brief. State whether the project is a Commander deck, Cube module, gift deck, token set, or display project. Record the intended visual mood, the information that must remain easy to recognize, and who has final approval. Also decide how many formal proof rounds the schedule allows; otherwise, small stylistic experiments can continue indefinitely.

Write one sentence that acts as the visual rule. For example: “A moonlit storybook deck using indigo shadows, warm gold highlights, centered portraits, and restrained constellation motifs.” That sentence is specific enough to reject art that is attractive but incompatible.

Then define controlled variation. The commander can receive a distinctive border, removal spells can use sharper red accents, and lands can feature quieter compositions. A deck-wide system works best when palette roles, recurring motifs, category rules, and deliberate exceptions are documented rather than remembered informally. Review those choices both on individual cards and across a simulated battlefield. The deck-wide color-palette guide provides a deeper method for assigning those roles.

2. Lock a master card list with stable IDs

Do not use filenames as the only deck database. Create a master list in which every physical piece receives a stable project ID, such as CMD-001, LAND-014, or TOK-006. A stable ID should remain attached to the asset even if the card name, artwork, or layout changes.

Tracker field	What to record	Why it matters
Project ID	Unique, permanent identifier	Keeps revisions and exports connected
Card record	Name, quantity, deck role, current status	Shows what belongs in the frozen list
Art record	Source filename, artist or source, crop version	Prevents assets from becoming anonymous
Rights note	Owned, commissioned, licensed, permission pending, or unresolved	Flags assets requiring case-specific review
Layout record	Frame family, front version, back assignment	Connects each card to approved templates
Special handling	Token, DFC, emblem, saga, battle, meld, or other exception	Prevents unusual pieces from disappearing during export
Approval	Reviewer, date, and approved version	Identifies the production master

Include likely cuts while the deck is still changing, but mark them as provisional. When design work is ready to become production work, duplicate the list, label it with a version and date, and freeze it. Later changes should create a new production version rather than silently altering the old one.

3. Build and test the visual system

Before producing every layout, make a representative test set of roughly the project’s visual extremes: the commander, a dark card, a bright card, a text-heavy card, a land, a token, and one unusual layout. The purpose is not to perfect seven isolated cards. It is to expose system-level weaknesses while they remain inexpensive to fix.

Check whether titles, costs, type lines, rules text, and power/toughness information occupy predictable locations. Protect those information areas from busy focal points. If an illustration only works when its important subject sits under the rules box, either choose a different crop or a different image.

Use category rules to reduce inconsistency. Creatures might use close portraits, instants might use wider action scenes, and artifacts might share a geometric frame accent. Exceptions should identify genuinely important cards rather than becoming rewards for whichever image was hardest to crop.

4. Track artwork, permissions, and source notes

Keep the original asset separate from every edited crop. Record the creator or source, acquisition date, relevant permission or commission note, required attribution, and any restriction that needs review. A folder full of downloaded images is not a rights record, and the existence of a license does not by itself establish that a particular print run is permitted. Resolve uncertain cases individually before final approval.

Use predictable filenames such as CMD-001_art-source, CMD-001_crop-v03, and CMD-001_layout-v05. Avoid final, final2, and final-really-final. The approved tracker entry—not the optimism of a filename—determines which file is the master.

5. Approve fronts and one master back

The front layout needs rules for framing, typography, symbols, borders, and unofficial identification. The back needs the same discipline. Approve one master back, apply it consistently where a normal back is appropriate, and inspect it at physical card size. Predictable version names make later corrections much safer. For logo scale, clear space, and contrast, use the custom proxy back design guide.

Keep the back visually simpler than a typical front. A project name, restrained motif, and clear unofficial marker usually survive reduction better than a collage of references. If the back includes a deck logo, test whether it remains recognizable without becoming so dominant that it resembles packaging rather than a playing piece.

6. Treat lands as their own subsystem

Lands appear repeatedly and form a large visual mass on the battlefield, so they need a group proof rather than scattered approval. Decide how each basic-land type will be recognized, whether copies repeat or use variants, and which palette or compositional rule connects the cycle to the rest of the deck.

A project does not need unique art for every basic-land copy. Repeating a strong design can improve recognition and reduce the number of assets requiring approval. The matching basic-land cycle workflow explains how to balance repetition, variation, and land identity.

Nonbasic lands also need a rule. They can share the land frame while using a different accent, carry location-focused compositions, or form smaller visual families. Whatever approach you choose, confirm that lands remain distinguishable from spells when several cards are on the table.

7. Audit tokens, emblems, and helper pieces

Read the frozen deck list specifically for generated objects and gameplay aids. Record the source card, object name, relevant characteristics, expected quantity, and whether multiple source cards can share one helper design. Include copy markers, emblems, reminders, and project-specific reference cards only where the deck actually needs them.

Tokens should belong to the deck without being mistaken for cards in the main library. A dedicated token border, bolder type label, simplified text treatment, or shifted palette can create that distinction. Planeswalker emblems deserve the same coordinated treatment; the site’s special-card collection includes a focused custom emblem design guide.

8. Resolve DFCs and unusual layouts before export

Double-faced cards cannot be handled as ordinary fronts with the project’s standard back. Wizards explains that these cards have two faces instead of the normal Magic back, and hidden-zone use may require opaque sleeves or substitute cards. Check the current official Magic rules materials before choosing a play solution because rules details can change.

Give each face its own asset entry, then add a shared pair ID. Record front-to-back mapping, orientation, filename, and the intended hidden-zone method. Make the faces feel related through palette or motifs, but preserve a clear visual state change so players can recognize which face is active.

Use the same exception-first planning for split cards, adventures, sagas, battles, planeswalkers, flip cards, and meld components. Flag them before bulk layout begins. Trying to force every unusual card into a standard template at the end usually creates rushed crops and inconsistent exports.

9. Use revision control that survives a large deck

Create separate folders for source art, working crops, editable layouts, review proofs, approved masters, print exports, and archives. Restrict the approved-master folder to files that match the tracker’s recorded version. Production exports should be generated from those masters, not copied from email attachments or reviewer folders.

Start filenames with the stable project ID.
Use two-digit or three-digit versions consistently.
Add status words such as WIP, REVIEW, or APPROVED only when the tracker agrees.
Never overwrite the exact package sent for production.
Record replacements as new versions with a short change note.
Archive templates, fonts, linked assets, and mapping documents needed to recreate the project.

10. Run two different proof passes

Card-scale proof

Inspect every design at its intended physical size, not only while zoomed in. Check title and rules-text readability, crop quality, symbols, type lines, color contrast, borders, unofficial identification, and whether critical art details become muddy. Also compare the exported image with the approved layout so missing fonts, shifted elements, or stale assets are caught.

Battlefield-scale proof

Arrange a representative board containing creatures, lands, tokens, the commander, and several card categories. Step back and ask whether card roles remain recognizable, whether lands separate from spells, and whether repeated motifs create cohesion without visual monotony. Card-scale proof catches local defects; battlefield-scale proof reveals whether the project works as a deck.

11. Assemble the final print handoff

Provider requirements are not universal. Confirm the selected service’s current template, image dimensions, bleed, color mode, accepted file types, front/back mapping method, naming rules, and content policies. Do not resize or convert every approved master based on an assumed specification.

The handoff package should contain the frozen deck list, final fronts and backs, a mapping sheet, token quantities, special-card notes, a contact sheet, the version log, and a copy of the confirmed requirements. Keep editable files separate from production exports. If the next step is ordering through a custom MTG proxy printing service, use a duplicate of the approved handoff package so the archive remains untouched.

Frequently asked questions

What belongs in a proxy deck asset tracker?

At minimum, include a stable ID, card name, quantity, role, art filename, artist or source, rights note, crop version, layout version, back assignment, special-card flag, approval status, and change notes. Add provider-specific fields only after choosing the production route.

Do all basic-land copies need unique artwork?

No. Repeating one approved design per basic type can create stronger recognition and less asset-management work. Use variants only when they support the visual concept without weakening consistency.

What should a custom proxy back include?

Use a legible project identity, strong contrast, sufficient clear space, and an obvious unofficial marker. Keep one approved master for ordinary-backed cards and handle functional second faces separately.

Why proof at both card and battlefield scale?

A close proof reveals text, crop, alignment, and export problems. A battlefield proof reveals category confusion, weak land recognition, excessive repetition, and palette imbalance. Neither view can replace the other.

How do I prevent last-minute version confusion?

Freeze the production list, use stable IDs, record every approved version in one tracker, and generate exports only from the approved-master folder. Preserve the submitted package exactly as sent.

Finish with one source of truth

The final design rule is procedural: one frozen list, one current tracker, one approved master for each asset, and one archived handoff package. When those four records agree, the project is ready to leave the design stage. If they disagree, fix the records before producing another export. That pause is much cheaper than discovering after handoff that a cut card, outdated back, missing token, or reversed DFC mapping survived into the final batch.