Before I build anything — for myself, for work, for a client — I run it through the "Is It Stupid?" check. It's three questions. If the idea survives all three, it's probably worth building. If it doesn't, I just saved myself weeks or months.
This isn't some productivity framework I read about. It came from a real job.
Where It Came From
I used to work at a company that built what we called "line of business" applications. Basically, custom SaaS apps built for a single company with a very specific need.
A construction cleaning company needed scheduling and job site tracking. An armored truck company needed digital forms for bank pickups and drop-offs. A highway signage company needed field workers to photograph installed signs, mark GPS coordinates, and send it to the county to get paid.
We got pitched ideas constantly. Some were great. A lot of them were not. And we got very good at figuring out which was which before we spent any time building.
We joked about changing the company name to IsItStupid.com.
The Three Questions
1. Will users actually do this?
This is the one that kills most ideas. You can build the most elegant system in the world, but if you're expecting a field worker standing in the rain next to a highway to fill out a 15-field form on their phone, it's stupid. If you're expecting a bank teller to add a step to a process they've done the same way for 20 years, it's stupid. If you're expecting anyone to enter data they don't personally benefit from entering, it's stupid.
The software has to fit into the user's actual life, not the life you imagine for them from a conference room.
2. Do the real-world constraints even allow this?
Cloud-dependent functionality in a tunnel with no cell service. Real-time GPS tracking on devices that are turned off half the day. Syncing data between locations that have different internet providers with different uptime guarantees.
Every idea sounds great in a room with Wi-Fi. The question is whether it works in the actual environment where it has to run. If the answer is "well, they'd need to upgrade their infrastructure" — it's stupid. They won't.
3. Is it stupid to build this just once?
This was the business question. If we're building scheduling software for one cleaning company, are we writing it as a one-off? Or are there parts of this — the scheduling engine, the job site check-in flow, the reporting layer — that we'd use again for the next client?
It wasn't about whether the idea was stupid. It was about whether our approach to building it was stupid. Writing the same scheduling logic from scratch three times in a year is stupid. Building it once as a reusable module is not.
How I Use It Now
I run everything through the check. My own projects, features at work, side ideas that sound fun at 2 AM.
When I decided to build my own AI health system, the check went like this: Will I actually use it? Yes — I'm already talking to LLMs about my health every day. Do the constraints allow it? Yes — I have a phone, an API, and a database. Is it stupid to build just for me? Maybe — but my wife wants one too, and the persona system means I can support multiple users without rewriting anything. Passed.
When I built the karaoke production platform, same thing. Will the band actually use the ready check system? We're already squinting across a dark stage for thumbs up — yes, they'll use it. Do the constraints allow it? Local network, everyone already has phones — yes. Is it stupid to build as a one-off? Maybe, but I'm solving my own problem and the show is in a month. Build it, figure out reusability later. Passed.
The ideas that don't pass usually fail on question one. "The user will just..." No they won't. They never "just" do anything. If your idea requires humans to change their behavior with no personal incentive, it's stupid.
The Point
I'm not saying every idea needs to survive a formal review. I'm saying that before you invest real time, run it through three questions: Will users actually do this? Do the real-world constraints allow it? Is it stupid to build it this way?
If you can't confidently answer all three, you're about to waste your time. And time is the one thing you can't refactor.