A Non-Engineer Built an
MTG Price-Comparison Site
from Scratch in Five Days with AI
I do not usually build web services by writing the code myself. Yet with ChatGPT and Codex, I built MTG PRICE CHECK, a price-comparison site dedicated to sealed Magic: The Gathering products. It took about four working days to build the core features, and about five days to get the site ready for launch, including UI refinements, data review, SEO, security, and affiliate setup. This is a record of that process.
Visit MTG PRICE CHECK ↗
This Was More Than a Page of Product Links
At launch, the site listed 150 sealed products: 135 already released and 15 upcoming or available for preorder. I built a functional web service with product search, set pages, product details, price history, price-drop rankings, new and upcoming releases, and buying guides.
I also built a system that retrieves prices daily from Rakuten and Yahoo! Shopping APIs, checks product attributes, saves price history, and regenerates pages. The project also covered links to retailers including Amazon and Suruga-ya, affiliate disclosures, a privacy policy, explanations of price data, Search Console, Google Analytics, a sitemap, robots.txt, automated tests, and a security audit.
At a glance, it may look as if I gave AI instructions and got a finished site in no time. But I spent more time deciding which listings count as the same product, which prices to trust, and what to display when a price cannot be retrieved than I did building screens.
AI dramatically increased implementation speed.
That madeThe weight of design and judgmentmore important than ever.
I Had to Learn the Basics of an Affiliate Publisher While Building the Site
I had experience running e-commerce sites, but I had never operated an affiliate business that sent customers from my own site to Rakuten, Yahoo! Shopping, Amazon, and other retailers for commission. So alongside development, I reviewed the programs, user flows, and terms for Amazon Associates, Rakuten Affiliate, ValueCommerce, Yahoo! Shopping, and Suruga-ya.
Fetching prices through an API and linking users to a retailer through an affiliate link serve different purposes. I added a clear advertising disclosure and disclaimers, made sure commission rates would not affect product rankings, and set a policy of showing prices only after they pass product matching.
ValueCommerce declined my first application. I improved the site’s publisher information, articles, product pages, and disclosures, then reapplied and was approved later. Passing an external review was one indication that the site had moved beyond simply displaying pages and toward meeting the basic requirements for an affiliate publisher.
Before Fetching Prices, Define What Counts as the Same Product
Sealed Magic: The Gathering products can have similar names but different contents. The catalog includes Japanese and English editions, Play Boosters and Collector Boosters, boxes and individual packs, single and multi-box listings, Bundles and Gift Bundles, individual and set versions of Commander decks, standard and limited editions, and preorder and released products.
If the lowest price were chosen by partial name matching alone, a cheap individual pack could be mistaken for a box price. An English edition could appear when the user wants Japanese, or a multi-box set could be mistaken for a single box. That might produce an attractive low price, but the comparison would be meaningless.
- Accept matches based only on partial product names
- Mix languages and units of sale
- Include out-of-stock listings in the lowest-price result
- Fill missing prices with guesses
- Check set, language, product type, and quantity
- Exclude products that do not meet the criteria
- Compare only verified products that are in stock
- Show that a price is unavailable when it cannot be verified
The key backend challenge was not retrieving a large volume of data; it was using only data whose conditions could be verified. When no price could be fetched, the site displayed messages such as “There are currently no prices to compare” and “Check the retailer’s page for the latest information.” The design does not present unknown information as if it were known.
I Didn’t Treat AI’s First Draft as the Finished Design
I delegated most frontend implementation to Codex. I personally reviewed what users need to know first, how someone can search without knowing a product name, routes for browsing by set or product type, the order of filters, what each price means, and how much information appears on mobile.
The search screen can be filtered by product name, set name, set code, product type, language, release and stock status, current price, Standard-legal sets, and sort order. Both the search screen and homepage explain that the current price is for the product itself and does not include shipping or reward points.

I revised image heights, title wrapping, information hierarchy, button labels, spacing, and the amount of information on product cards many times. AI can write code quickly, but it does not automatically spot everything that looks wrong on screen or might confuse a user. The process needed a clear division of work: a person designs, AI implements, and a person reviews the actual interface.
Keeping Daily Updates Reliable Is Harder Than Building Once
A price-comparison site cannot be finished by publishing static HTML once. Prices and inventory change, so I built a daily process that fetches candidate products from Rakuten and Yahoo! Shopping APIs, matches them, saves in-stock prices to a history, and regenerates the public pages.

Product detail pages show the current lowest price, the lowest and highest prices in the recorded period, the 30-day low and median, change from the previous week, price history by retailer, the date prices were checked, and the measurement period. If 30 days of data are unavailable, the site does not estimate them; it reports figures for the period actually measured.

I accounted for API failures, no matching candidates, false matches, and empty price data. For a service that supports purchase decisions, it is more important to state honestly that information is being checked than to force old or estimated prices onto the page.
One Product Page Grows from Preorder to Release
Upcoming and preorder products may not yet be listed by retailers. In that case, the site does not invent a price; it shows that price information and history are unavailable and directs users to check the retailer. Once sales data becomes available, the history is added to the same product page.

I also generated set pages so users can browse without remembering exact product names. Each page brings together the set name and code, Japanese and English names, release date, number of listed products, product types, languages, and verified price ranges. I adjusted the order so the main box products appear first.

I Built Pages to Resolve Purchase Questions, Not Just Attract Search Traffic
A price list alone does not help a beginner understand the differences between products. I added explanations of Booster Boxes, Collector Booster Boxes, Commander decks, Bundles, Starter Kits, and Gift Bundles, as well as advice on choosing sleeves, deck boxes, storage supplies, playmats, card loaders, dice, and counters.

The first articles generated by AI were shallow, awkwardly structured, vague, sometimes described nonexistent features, and missed search intent. Product images could also include retailer-specific promotional text, so I separated images used for purchasing from those used for explanation. Rather than increasing the article count, I gave each page a role in answering questions users have before choosing a product.
I reviewed SEO across the site, not just the articles: product and set pages, internal links, page titles, meta descriptions, headings, consistent product and set names, duplicate content, the sitemap, and robots.txt. I also verified that Search Console and Google Analytics were receiving data, rather than merely checking that their tags were present.
The security review covered API keys, tokens and secrets, personal information, unintended external requests, third-party scripts, XSS, injection, open redirects, input validation, dependencies, GitHub Actions, deployment settings, HTTP headers, CSP, and information exposed by errors. Codex implemented changes, ChatGPT reviewed them, Codex made fixes, and the cycle repeated after testing.
I Used AI as a Small Development Team, Not a Magic Button
In this project, I acted as product owner, project manager, and UX lead; ChatGPT handled design and audits; and Codex handled implementation. Separating the roles let me move between implementation and review instead of relying only on an AI’s assessment of its own work.
What I Decided
- Problem, target users, and required features
- Criteria for matching and displaying products
- UI/UX, user flows, and information priorities
- Spotting issues and making the final launch decision
Design and review
- Structuring requirements and problems
- Organizing revision instructions for Codex
- UI/UX, SEO, and security reviews
- Defining test cases and priorities
Implementation and verification
- Frontend and backend
- API integrations, page generation, and daily updates
- Search, history, charts, and additional tests
- Builds, verification, and Git diffs
Rules We Kept in the Project
- Prices that may be shown and prohibited practices
- Distinctions between language, product type, and quantity
- Editable scope and testing methods
- Actions requiring human approval and completion criteria
During development, unrequested information was added, the same content appeared twice, and display criteria changed without approval. I moved the site’s purpose, price definitions, prohibited practices, design rules, editable scope, testing methods, and completion criteria into project instruction files. Once the decision criteria lived alongside the code, the output became much more consistent.
I Didn’t Replace Outsourcing Costs; I Made Something Possible to Build
The scope included requirements, UI/UX, frontend work, API integrations, product matching, price history, daily jobs, data design, SEO, content, quality assurance, security, deployment infrastructure, and external service registration.
I asked AI to review the implementation scope and break down the phases and staffing a typical design or development company might need. Its estimate was that a project of this scale would usually cost around ¥3–5 million. This was not a formal quote, but given the requirements, UI/UX, APIs, product matching, price history, daily updates, SEO, security, and deployment infrastructure, I considered it a plausible range.
The point is not only that AI may have saved that amount of money. It let me take an idea I would not have started because of technical barriers and release it as a working service using my own time and AI subscription costs. The economics of development change not only when the same thing costs less, but also when it becomes possible to test something that could not be built before.
Not Everyone Can Build the Same Thing in Five Days
I do not think anyone can subscribe to ChatGPT and Codex and build this same site in five days. AI accelerates implementation, but people still need to decide what to build and whose problem it solves, what must not be displayed, whether the data is correct, whether users could be misled, which feedback to accept, and whether the site is ready to launch.
I repeatedly revised title placement, image height, information priorities, duplicate content, listing density, price explanations, search-filter order, and display rules that had not been requested. Whenever an issue arose, I identified what felt wrong, worked through the cause with ChatGPT, asked Codex to fix it, tested the result, and reviewed the screen.
I do not yet know how much revenue the site will generate. Still, I have one working product that brings together marketing, e-commerce, UX, data design, API integrations, automation, SEO, security, quality management, AI agent coordination, and project management. A functioning site can be a stronger portfolio piece than listing those experiences in text.
Next, I plan to continue daily updates and monitor search queries, impressions, click-through rates, landing pages, outbound referrals, update jobs, and product matching. Rather than keep adding features right after launch, I will use real data to decide what to do next.