You find a tiny app that does one thing. It looks buildable. The screenshots are plain. Your brain has already opened a new project.
Keep the project closed for another hour.
Competitor research is most useful before you become attached to your own explanation of why the app works. The aim is to finish with a decision: investigate, test, or move on.
Start with a scene, not a category
“Productivity” is a store aisle. “Remember the things I promised during a client call” is a problem. Write down the moment when someone reaches for help, what they currently do, and what failure costs them.
Then choose three rivals: the obvious app, a smaller specialist, and the workaround. The workaround might be a spreadsheet, a WhatsApp message to yourself, or doing nothing. It belongs in the comparison because it competes for the same decision.
Make one small table
| Question | What to record |
|---|---|
| Who needs this? | A specific user and situation |
| What is the promise? | The outcome shown in the listing |
| How does it get paid? | Visible price, trial, purchase or subscription terms |
| What annoys users? | Dated review examples, including counterexamples |
| How might users find it? | An observed channel, separated from your hypothesis |
| Why switch? | A meaningful advantage you could demonstrate |
| What remains unknown? | Retention, revenue, acquisition costs or anything unmeasured |
Keep links and dates beside the entries. “Lots of people hate the interface” is an opinion. Three recent reviews describing the same failed task are a lead you can investigate.
Look for an awkward truth
Suppose your imaginary voice-note app promises automatic action items. A rival is expensive, but users praise its reliability. Another is cheap, but misses names. Your opportunity might be accurate client-call summaries for a narrow profession. It probably isn’t “the same thing with a nicer purple button.”
Now write the strongest reason your idea could fail. Perhaps customers won’t upload confidential calls. Perhaps their existing meeting tool already solves enough of the problem. That paragraph deserves as much attention as the feature list.
End with a test you can lose
Recruit a few people who recently experienced the problem. Show a sample result and ask them to use it on a real task. Decide beforehand what would make you stop: no repeated need, no willingness to switch, or no credible way to reach more users.
A useful research session doesn’t always produce a startup. Sometimes it gives you your weekend back.