Personal Product
Built a production game-compatibility platform that checks 367,825 titles against a detected PC rig and returns FPS estimates, bottleneck analysis, and a Rig Power Score. Designed a deterministic IGDB + Steam read-layer pipeline with phase-based builds, blue-green swaps, and post-swap canaries, then served the catalog through a read-only database gateway with a graceful degraded mode for the self-hosted origin.
Key metrics and achievements that define this project
Explore the live demo, check the code, or reach out to discuss it
Full Case Study
A production game-compatibility platform that checks 367,825 titles against a detected rig. The build pairs a 13-phase IGDB + Steam read layer and a journaled blue-green swap with a Next.js runtime that reads precomputed compatibility by game, hardware hash, and resolution - then degrades gracefully when the self-hosted origin goes offline.
Answering 'can my PC run this?' at catalog scale means reconciling messy IGDB and Steam requirements, normalizing CPU and GPU names, and serving hundreds of thousands of game pages without querying ingestion collections or paying a per-request compatibility cost.
Separated ingestion from serving: IGDB and Steam land in source namespaces, a deterministic 13-phase build materializes read.* collections (requirements, hardware reference, compatibility cache, search, discovery, dashboard), and a journaled blue-green swap promotes the new layer only after validation gates and canaries pass. The Next.js app queries the read layer through a read-only executor, resolves the saved rig server-side, and reads compatibility precomputed by game, hardware hash, and resolution.
The hardest part of a data-heavy product is not the UI; it is making the data pipeline deterministic, observable, and reversible. Treating the build as a product surface - with phase contracts, validation gates, and rollback - made it possible to ship a large catalog on a self-hosted origin without turning every data change into an outage risk.
A phase-by-phase record of how the work was scoped, built, and carried into production.
Mapped the user question, the available IGDB and Steam fields, and the places where the source data could not answer it cleanly.
The product needed a normalized hardware layer before it could make a credible compatibility claim, so discovery covered both game data and CPU/GPU identities.
The build started with a data contract instead of a UI-first prototype.
Separated ingestion, staging, runtime, and rollback namespaces, then defined a deterministic phase order with validation gates and a journaled swap.
Runtime queries are constrained to read.*; a separate build gateway owns writes so the public runtime credential is read-only.
Implemented hardware detection, a saved-rig flow, and compatibility surfaces backed by hardware_reference and compatibility_cache.
Compatibility is keyed by game_id, hardware_hash, and resolution, with resolver provenance exposed for exact, case-insensitive, fuzzy, and unknown matches.
FPS estimates, bottleneck analysis, and the Rig Power Score became read-path features rather than per-request calculations.
Materialized slugs, discovery pages, search entities, ranking signals, and metadata for a 367k-title catalog.
The same build drives page generation, search, and ranking so they cannot drift into separate truth sources.
The catalog is searchable and crawlable without querying source collections at request time.
Published methodology, accuracy, data-source, and corrections pages, plus a versioned dataset export and AI-ingestion files.
A Cloudflare cache rule serves stale pages when the origin is down, and a Worker plus heartbeat provide a designed fallback instead of Error 1033.
The public launch covered both discoverability and the operational failure mode.
Key Decisions
A compact snapshot of the technical and product decisions that had the biggest impact on delivery.
IGDB and Steam data is large, normalized differently, and not shaped for page rendering. Serving it directly would couple request latency to ingestion state and make every schema change a runtime risk.
I built a deterministic phase pipeline that materializes read.* collections and promotes them as one versioned unit.
Impact: Runtime queries stay stable and fast, and a bad build can be rolled back as a whole.
Tradeoff: The pipeline is more infrastructure than a conventional CMS-backed app.
The public app only needs to read the catalog, while ingestion and the read-layer build need write access to staging and metadata collections.
I routed runtime reads through a read-only executor and kept writes behind a separate build gateway and key.
Impact: A compromised runtime credential cannot mutate source or staging data.
Tradeoff: There are two endpoints and two secrets to operate.
Compatibility is the core product surface, and recalculating it for every card and page would dominate request time.
Phase07 builds the hardware reference and compatibility cache, and the runtime reads the precomputed result with resolver provenance.
Impact: Cards and pages can show FPS and tier signals without a per-request comparison.
Tradeoff: The build has to keep hardware aliases and benchmark scores fresh.
The production origin runs on a laptop behind a Cloudflare tunnel, so power or network loss would otherwise surface as a raw Error 1033 page.
I added a serve-stale cache rule, a Worker-based degraded page, and a heartbeat to keep the failure mode intentional.
Impact: Visitors see the last good catalog or a designed upgrading page instead of an infrastructure error.
Tradeoff: The fallback adds Cloudflare configuration and a heartbeat process.
Visual Showcase
This screen captures the production-facing design language, layout rhythm, and overall polish of the experience.
Scroll to explore technologies →
Keep Exploring
Commit streaks, language breakdown, and delivery cadence for the repos behind this build.
Open /githubFree embeddable GitHub stat cards powered by the same sync pipeline this site runs on.
Browse the galleryRelated writing selected by shared topics for project myrigcheck.
