# signal - rand-x-gen

# I Got Sick of Choice Paralysis, So I Built a Site With Only One Button

Every content platform I use has converged on the same pattern: an infinite grid of thumbnails, a search bar, filters, "recommended for you," related content sidebars. More options, more metadata, more decisions before you've even started doing the thing you opened the app to do.

I wanted to see what happens if you remove all of it.

So I built **SIGNAL** — a single-purpose site with exactly one piece of content on screen at a time, and exactly one action: skip to the next one.

## The problem with choice

There's a well-documented psychological effect where more options don't make people happier — they make people more anxious, more likely to second-guess themselves, and often less satisfied with whatever they eventually pick. Most platforms are built the opposite way: engagement metrics reward *browsing*, not *deciding*, so the incentive is to keep you scrolling through options rather than landing on one.

I wanted to try building something that optimized for the opposite outcome — get in, experience one thing, decide "next or not," repeat. No feed to scroll, no thumbnails to scan, no algorithm to guess your taste. Just a stream.

## How it works

SIGNAL doesn't host or store any content itself. It pulls clips live from public aggregator APIs and plays them through their official embeds — the site is essentially a thin, stateless client sitting on top of existing infrastructure. There's no database of "your history," no account system, no recommendation model to train.

The interface is intentionally minimal:

*   One item on screen
    
*   One button: **Next**
    
*   An optional "tuner" that lets you nudge the kind of content you get (length, style) without ever showing you a menu to pick from
    

That's the whole product surface. No search, no categories, no related-content rail.

## Why build it this way

A few things I was testing:

1.  **Does removing choice actually reduce fatigue?** Anecdotally, yes — sessions feel shorter and more decisive when there's nothing to compare against.
    
2.  **Can a "dumb" aggregation layer be a legitimate product?** SIGNAL doesn't compete on catalog size or exclusive content — it competes on *not making you choose*. That's a different kind of value proposition than most content platforms chase.
    
3.  **What does a stateless, embed-only architecture look like at small scale?** No storage costs, no hosting liability for the actual media, minimal backend — just an API aggregation and randomization layer, deployed on Render.
    

## What's next

I'm continuing to iterate on the "tuner" concept — figuring out how much control to expose before it turns back into the choice-paralysis problem I was trying to avoid in the first place. That tension (some control vs. no control) has turned out to be the most interesting design problem in the whole project.

GitHub: **https://github.com/eyeblech/signal** Live: **\[**[https://signal-vl1k.onrender.com/](https://signal-vl1k.onrender.com/)**\]**

* * *

*Note: SIGNAL is an 18+ platform. This post is about the product/UX architecture, not the content itself.*