The Slop Test
You had an AI idea. Someone called it slop. Maybe they were right. Maybe you had not done enough work yet to know. Seven questions to find out.
You had an idea. You told someone about it. They said “that is just AI slop.”
Maybe they were right. Maybe you had not done enough work yet to know. Maybe the idea is genuinely good and you just could not explain it. Or maybe it is slop, and nobody around you had the framework to tell you why.
Both of these failures are happening constantly. Good ideas die because the person pitching them has not done the homework. Bad ideas get funded because nobody asks the basic questions. The root cause is the same: people are skipping the validation work.
The Two Failure Modes
Failure mode one: You have a real idea that solves a real problem, but when you describe it, it sounds like every other AI product. You use the same words everyone uses. You have not researched who else is doing it. You cannot explain it without jargon. People dismiss it, and you lose the collaborators and support you need to build it properly.
Failure mode two: You have an idea that is, in fact, slop. A thin wrapper around an API. A solution looking for a problem. But because AI is exciting and the demo is impressive, nobody challenges you until you have spent months or years building something that does not matter.
The first failure is tragic. The second is wasteful. Both are avoidable.
The difference between a good AI idea and slop is not the technology. It is the work you have done before writing a single line of code.
The Homework Nobody Does
Most AI builders skip straight from “I had an idea” to “I am building it.”
They do not research competitors. They do not talk to people who have the problem. They do not explain their idea to anyone who might disagree. They cannot describe what they are building in plain language. They have not written down their assumptions.
Then they are surprised when people call it slop.
Sometimes it is slop. A chatbot with a nice interface is not an innovation. A to-do list that calls itself “AI-powered” is not solving a new problem. A product that stops working when OpenAI changes its pricing is not a business.
But sometimes it is a genuinely good idea that sounds like slop because the builder has not done the groundwork. They have the right instinct but they have not done the research, gathered the feedback, or tested the assumptions that would let them explain why this matters.
The AI space has a vocabulary problem. Everyone says “AI-native.” Everyone says “autonomous.” Everyone says “intelligent.” These words have been used so many times on rubbish products that they no longer mean anything. If your pitch uses the same words as the slop, you will be treated like slop. That is not fair, but it is reality.
The fix is not better marketing. The fix is doing the homework that lets you speak specifically instead of generically.
“I built an AI tool” means nothing. “I built a consent management system that uses cryptographic binding so the safety constraints cannot be switched off” means something. The difference is not intelligence or talent. It is preparation.
Seven Questions
These are not abstract. These are practical. If you cannot answer “yes” to all of them, you have more work to do before you build, pitch, or ask for help.
We built an interactive version of this if you want to score yourself.
1. Does this problem affect a lot of people?
Not “does this interest me.” Not “could this theoretically matter.” Does this problem affect real, identifiable people, and can you name some of them?
If you cannot point to specific communities, professions, or groups who are actively struggling with this problem, you might be solving something that does not exist. The best test: talk to people who might have the problem. Not other builders. Not investors. The actual people.
If they do not recognise the problem when you describe it, that is information. If they light up because someone finally gets it, that is also information.
2. Have you researched who else is working on this?
Not “I think I am the first.” Have you actually searched? Thoroughly?
Search GitHub. Search Product Hunt. Search Crunchbase. Search Google Scholar. Search Reddit. If someone is already building what you are building, that is not a reason to stop. It is a reason to understand what they have learned, where they are falling short, and whether you are actually doing something different.
If you find ten competitors and cannot articulate how your approach differs, you have a positioning problem. If you find zero competitors, either you have found a genuine gap or you have not searched hard enough. The latter is more common.
3. Have you looked at what people are saying online?
Reddit, Twitter, LinkedIn, niche forums, industry Slack groups, Discord servers. Are people complaining about this problem? Are they asking for solutions? Are they working around it with duct-tape approaches?
If nobody is talking about this problem anywhere, find out why. Maybe the problem is real but the people who have it are not online. Maybe the problem is not as widespread as you think. Maybe you are using the wrong search terms because you are describing it in builder language, not in the language of the people who have it.
The internet is very good at complaining about problems. If your problem is real and widespread, there will be evidence.
4. Have you explained this to someone who disagrees with you?
Not your co-founder. Not your AI friends. Not someone who is already excited about AI.
Find someone who thinks AI is overhyped. Find someone who works in the domain your product serves but has never used AI tools. Find a family member who does not care about technology. Explain your idea to them.
If you cannot make them understand why this matters, your idea might be fine but your explanation is not. If they understand it and still think it is not useful, listen to why. The most valuable feedback comes from people who have no reason to be polite to you.
If you have only spoken to people who agree with you, you do not have feedback. You have an echo chamber.
5. Can you test this with real people?
Not “I showed someone a demo and they said it was cool.” Can you put this in front of people who have the problem and measure whether it actually helps?
“It feels useful” is not a test. What would success look like, measured in something other than your own enthusiasm? Fewer errors? Less time spent? Better outcomes? Measurable improvements?
If you cannot define what success looks like before you build, you will not know whether you have achieved it after.
6. Can you explain it without jargon?
No “AI-native.” No “autonomous agents.” No “leveraging large language models.” Can you explain what this does in words that a stranger on the street would understand?
If your pitch requires the listener to already believe in AI, it is not a pitch. It is a prayer. The best products solve problems that people already know they have, using language those people already use.
Try this: describe your product to someone without using the word “AI” at all. If what remains still sounds useful, you might have something. If what remains is “it is a chatbot,” you need to think harder.
7. Have you written down your research, your assumptions, and what you do not know?
Writing it down forces clarity. Keeping it in your head allows vagueness.
You do not need an academic paper. You need a document that answers:
- What problem am I solving?
- Who has this problem?
- What exists already?
- What am I doing differently?
- What assumptions am I making?
- What do I not know yet?
- What could go wrong?
If you cannot fill this out, you are not ready to build. If you can, you have a foundation that makes every conversation, pitch, and decision easier.
This does not need to be formal. It needs to be honest.
Finding People Who Can Help
If you have done the homework and your idea holds up, the next problem is finding collaborators. The AI space is noisy. The people who can help you are overwhelmed with pitches from people who have not done any of the work above.
Here is how to stand out: do not go to the AI community first.
Go to the people who have the problem. If you are building something for healthcare, go to healthcare communities. If you are building something for education, talk to teachers. The people who understand the problem are better collaborators than the people who understand the technology.
Find open source contributors in the problem space. People who build in public, with real code, who have already been working on adjacent problems. They can evaluate your idea based on what it does, not what it promises.
Talk to academic researchers. Universities are full of people who have been studying the underlying problem for years. They know what has been tried, what has failed, and where the genuine gaps are. Many of them are looking for practical applications of their research.
Lead with the problem, not the technology. “I am building an AI product” gets you ignored. “I am working on a way to reduce medication errors in nursing homes” gets you a conversation. The technology is how you solve the problem. The problem is why anyone should care.
If you cannot find anyone who cares about the problem without mentioning AI, the problem might not be real. If people care about the problem but are sceptical of your approach, that is useful feedback. If people care about the problem and are interested in how AI might help, you have found your collaborators.
If you are working on something that involves AI safety, privacy, or consent, we can help. That is specifically what we do.
What You Can Do
If you are building an AI product:
Run yourself through The Slop Test. Answer honestly. For every question where the answer is “no,” do the work before you invest more time or money. If you score well, you have done more preparation than most. Now build it.
If you are evaluating AI products:
Use the same seven questions. Ask the builder: who has this problem? Who else is doing this? Can you explain it without jargon? What happens when it fails? If they cannot answer, that tells you something. If they can, listen.
If you are not sure whether your excitement about AI is healthy:
Check yourself with the AI Psychosis self-test. It is not a diagnosis. It is a mirror. Be honest about whether you are excited about the problem or about the technology. The former builds useful things. The latter builds slop.
The Slop Test, AI Safety Evaluation, AI Behavioural Testing, Release Decision Framework, Cross-Jurisdiction Compliance, and AI Psychosis are open tools. Use them on anything.
This post is licensed CC BY-SA 4.0. Share it, adapt it, use it. Just cite us.