Why I Built a Paid GPU Check and Hid the Buy Button

I approved one fixed-price written service on 2026-10-24, merged the code, and deliberately left the payment link turned off. The page is /gpu-buy-check under bmdpat PR 2109, commit a57c3ba1. It is the only merge across seven repos on 2026-10-24.

Two private keys from an autotrader are still sitting in git history on day five. The security audit reported RED: 6 P0, 27 P1, and 48 P2 issues. A Raspberry Pi root disk hit 100% capacity with 0 bytes free because system journals filled 4.1 GB against a 4.0 GB limit. The automated think routine timed out at 600 seconds.

I still wrote the review page. Then I stopped the checkout from taking money.

Open full-size image (opens in new tab)

Why ship a service page without a buy button?

A live checkout button over unverified intake plumbing masks your real demand numbers. If a form drops submissions or fails silently, you cannot tell whether visitors saw no value or hit broken software. Turning off the payment link forces you to verify page layout, traffic intent, and intake fields before claiming any conversion signal.

+------------------------------------+
| 750 Search Impressions             |
| 79 Hardware Query Terms            |
+-----------------+------------------+
                  |
                  v
+-----------------+------------------+
| 4 GPU Reference Posts              |
| Bridge line on 375, 768, 1440 px   |
+-----------------+------------------+
                  |
                  v
+-----------------+------------------+
| /gpu-buy-check Page (PR 2109)      |
| Payment link: OFF (No fake zeroes) |
+------------------------------------+

A search intent report showed 79 hardware queries and 750 impressions across four hardware articles. Readers search for specific cards, but free documentation never answers whether a specific card fits a specific budget.

If you run hardware workloads, you know that buying the wrong silicon wastes hundreds of dollars. Before checking any third-party listing, check your own model parameters against the 5090 local inference guide to see actual production throughput. Run your numbers through the VRAM calculator first. You can also read GGUF quantization explained to find out whether smaller weights meet your quality target.

The service draft lists its own historical failure modes right before the offer. Two prior asynchronous services sold zero units. With 750 impressions, standard click rates produce about 5 actual visits over 28 days. That means an honest baseline expectation is 0 to 2 total orders.

How do you kill an offer that fails?

You kill a failing offer by writing an automated expiration rule into your repo before launching. Commit 504924477a amends Rule 8 and creates gpu-buy-check-kill-rule-2026-11-28. It requires exactly two paid orders from strangers within 30 days to keep the page live.

Without an explicit rule, dead projects linger indefinitely on a website. Another service, Rig Fit, logged 16 views, 0 clicks, and 0 orders on 2026-10-24. A Python script at config/loops/rig_fit_verdict.py will record its verdict automatically on 2026-10-29. Unmeasured performance is never treated as a pass.

Across seven days ending 2026-10-24, user loops logged 1,471 human sessions, 30 clicks, and 0 install intents. In the last 24 hours of that window, the site saw 188 human sessions and 5 clicks. The numbers stay small, and hiding them solves nothing.

What should you do with this?

Audit your product pipeline for unverified claims, orphan projects, and hidden infrastructure failures.

1. Check your primary server disks for runaway log files that exhaust available capacity.
2. Search git commit histories for exposed authentication credentials and dependency CVEs.
3. Attach an explicit expiration date and a minimum order count to every new service page.

The report told me where money sits and I priced exactly that, not a service menu.

Accompanying prompt

What the prompt does: Evaluates hardware upgrade requirements against specific target model parameters and constraints before buying hardware.

Copy/paste this prompt:

Copy-ready prompt

Paste the exact block into your coding agent.

No article chrome, no footnotes, no formatting drift.

Copy promptSelect text

Role: Local Hardware Advisor Context: A builder is deciding whether to buy a specific GPU for local inference workloads and wants to avoid purchasing inadequate VRAM. Inputs: - Target Model: __ - Quantization Level: __ - Context Window Size: __ - Proposed GPU: __ - Proposed GPU VRAM: __ GB - Total GPU Cost: $__ Task: 1. Calculate the exact VRAM required for the model weights and the requested context window. 2. Determine if the proposed GPU can run this workload fully offloaded without system RAM spillover. 3. State whether the purchase is mathematically sound or if a different VRAM tier is required. Output: - Required VRAM estimate in GB - Fit verdict: YES or NO - Primary bottleneck description Constraints: - Rely strictly on mathematical memory requirements. - Do not recommend enterprise cloud hosting as an alternative.

26 lines/838 chars

Ready

This prompt and every other one we publish live in the free prompt library.

Copy the block above.

Weekly measured local runs: https://bmdpat.com/5090-reports