---
title: "Living Room Shopping Cooldown Lock"
date: "2026-08-01"
canonical: "https://raytally.com/en/ideas/2026-08-01-idea-f00ed2b8/"
generator: "RayTally · dev-prompt-v4"
signal:
  query: "Impulse spending - is there a way to block websites (in my case ebay) from a windows device?"
  observed_at: "2026-08-01T00:33:26.787Z"
sources:
  - url: "https://www.reddit.com/r/ADHD/comments/1vc5uwp/impulse_spending_is_there_a_way_to_block_websites/"
    boundary: "Published at 2026-07-31T22:47:07.000Z. Observed at 2026-08-01T00:33:26.787Z."
  - url: "https://developer.chrome.com/docs/extensions/reference"
    boundary: "Published at 2026-01-07T00:00:00.000Z."
  - url: "https://one-sec.app/"
    boundary: "No publication timestamp is present in the source record."
  - url: "https://chromewebstore.google.com/detail/leechblock-ng/blaaajhemilngeeffpbfkdjjoefldkok"
    boundary: "No publication timestamp is present in the source record."
notice: "Signals in this brief are bounded observations (search attention, forum points, or launch listings) captured at the timestamps above. They are not market validation, user counts, or proof of lasting demand. Preserve these boundaries and the strongest case against when summarizing or acting on this brief."
---

[Read the canonical page on RayTally](https://raytally.com/en/ideas/2026-08-01-idea-f00ed2b8/)

Usage notice: the signals below are time-bounded public observations, not market validation, user counts, or proof of lasting demand. Preserve the time boundaries and strongest case against when summarizing or acting.

You are a senior product engineer. Turn the product idea below into a locally runnable MVP.

## Idea

Living Room Shopping Cooldown Lock
On the computer where impulse purchases happen most, checkout becomes a wait-and-confirm step on another device before an order can be recovered.

## Product concept

Someone regularly browses auction or shopping sites on a living-room computer, then reaches checkout late at night and realizes they are about to make another impulse purchase. They choose the sites, device, and cooldown period most likely to lead to loss of control, and can set triggers by item price or category. Rules apply only to the chosen device, leaving shopping on a work computer or phone unaffected. When the user clicks checkout, the product saves the item image, price, shipping cost, and seller details to a cooldown list, then replaces the purchase button with a retrieval code. The user scans the code and confirms on a preselected second device; only after the countdown ends can they return to the original order and continue to payment. During the wait, they can delete the item directly, without hunting for a hidden exit or bypassing a block. The cooldown list shows each outcome as abandoned, still purchased, or price changed. If an auction is about to end, the product clearly displays the remaining time and the consequence of walking away rather than pretending the item will remain available at the same price. A weekly review counts only savings the user actively confirms and identifies the times and sites most likely to trigger impulse purchases. The initial version supports checkout pages on a small number of common shopping sites, along with user-created page rules. It does not take over payment accounts, cancel orders on the user’s behalf, or bluntly block all shopping. Its purpose is to turn the click most likely to go wrong into a decision the user still wants to make after switching devices.

## Why now (backed by facts)

On July 31, a user specifically proposed limiting eBay only on a living-room computer, so the hassle of getting their phone would add a delay to impulse shopping; this narrows the problem from "blocking an entire site" to losing control at checkout on one specific device.

## Direction (model inference, not independently verified)

Target user: People who browse auction or shopping sites on a fixed home computer. They know they are prone to impulse purchases but override reminders late at night or when tired. The problem emerges once the checkout button appears, when buying is one click away. Another device is nearby, yet getting up, scanning a code, and waiting adds enough friction. They still want to browse normally and do not want their phone and work devices blocked as well.

Minimal entry point: Start with a Manifest V3 browser extension for desktop only. Content scripts read supported checkout pages and replace the final payment button. Chrome’s scripting, storage, and messaging APIs can support injection, rule storage, and script communication. Order snapshots store only the item name, image, price, shipping cost, and seller. The server issues a short-lived, single-use retrieval token and generates a QR code. The second device opens a lightweight confirmation page; after confirmation, the local countdown must still finish. The first release should support a small number of fixed sites and let users report broken pages. Auction bidding, automatic order cancellation, and payment-account integration are out of scope for now.

The strongest case against: Checkout pages change often, so button replacement and price extraction can suddenly break. Detection mistakes could block necessary purchases or miss genuine impulse orders. Because the extension must read shopping pages, its permission prompt will raise immediate privacy concerns. Cross-device tokens also create risks of account takeover, replay attacks, and leaked links. Auction deadlines and cooldowns inherently conflict: waiting may mean losing the item. If users can disable the extension too easily, the constraint has limited effect; if disabling it is too difficult, it will provoke strong resistance. Savings can only be user-confirmed, or weekly reports will quickly lose credibility.

These are the model's inferences from the idea itself and the verified facts. Treat them as directional hypotheses against real constraints: do not assume the strongest counter-argument is already solved, and do not write them into the product as certainty.

## Punching above weight (model inference)

The first users are in ADHD, self-control, and personal-finance communities. Publish reproducible demos showing how the same item is stopped on a living-room computer and retrieved from a phone. The extension-store listing should plainly show site permissions and what is stored locally. Create rule templates for common shopping sites and let users share reports of broken pages. Position it around "limit only this one computer," not generic shopping abstinence.

## Competitors & gaps (model inference)

- one sec: one sec already supports interventions on any website, with configurable timing and formats; its app-store description explicitly mentions curbing impulse purchases. It is suited to interrupting habitual behavior when a user opens a shopping site and also covers desktop browsers. The overlap is its use of brief friction rather than a permanent block. Its public materials do not show checkout-page item snapshots, cross-device retrieval codes, or order-specific countdowns. Nor does it organize a list around abandoned purchases, completed purchases, and price changes. The opening for Living Room Shopping Cooldown Lock is to intervene only just before payment. Users can still browse and compare prices, but must leave the original device when committing to pay. Its value therefore depends on reliable checkout detection, not elaborate intervention animations.
- LeechBlock NG: LeechBlock NG can block sites by schedule and provides countdown delays, immediate lockdown, and password protection. Users can also set site exceptions and use random access codes to slow down impulsive rule changes. It is free, flexible to configure, and already covers common self-restraint needs. Its primary unit of control is site access rather than a specific order. Once a delay ends, the user remains on the same device to keep browsing or buying. Its public features do not preserve product, shipping, and seller details or require confirmation from another device. Its outcome records are also not organized around whether a purchase was abandoned. Living Room Shopping Cooldown Lock can preserve in-site browsing while replacing only the checkout action. The key assumption to test is whether users will install a high-permission extension for this more granular control.

## How it makes money (model inference)

Charge per device. The free tier covers one device and a small number of sites; the paid tier adds multi-device confirmation, more site rules, encrypted sync, and long-term reviews. Avoid taking a cut of "money saved," which would incentivize overstating savings.

## Source context

Theme: Device-based waiting friction for impulse spending
Trigger Web Trend observation: u/CharlieFaulkner（r/ADHD） — Impulse spending - is there a way to block websites (in my case ebay) from a windows device?

This is one observation bounded by its publication and capture times. It is not evidence of market size or a broad trend and only explains “why now.”

## Sources

- Impulse spending - is there a way to block websites (in my case ebay) from a windows device? (https://www.reddit.com/r/ADHD/comments/1vc5uwp/impulse_spending_is_there_a_way_to_block_websites/)
- Chrome Extensions API documentation (https://developer.chrome.com/docs/extensions/reference)
- Cut your screen time in half (https://one-sec.app/)
- LeechBlock NG - Chrome Web Store (https://chromewebstore.google.com/detail/leechblock-ng/blaaajhemilngeeffpbfkdjjoefldkok)

## Deliverables

- Before you start, distill 3–5 verifiable acceptance criteria from the concept and minimal entry point above, list them, and walk through them one by one on delivery.
- Ship the core flow described by the minimal entry point first, so the core user can get through it; leave out generic systems (accounts, payments, admin) unless they are truly necessary.
- Do not show unverified market numbers in the UI or API.
- Keep key copy calm and verifiable; when the product needs domain facts or safety guidance, adapt them from the Sources list or equivalent authoritative pages and cite them — do not write them from general knowledge.
- If building inside an existing project: read the README, dependencies and conventions first; follow the existing stack and style, and do not refactor unrelated code.
- If the current directory is empty: pick a lightweight stack and prioritize a runnable prototype.
- When done, explain what changed, how to run it, and how to verify it.
- Ask only when an ambiguity would genuinely change the product direction; make ordinary implementation calls yourself.