Painkiller, Vitamin or Candy: the grid I use before coding an app
Before writing a single line, I classify the idea, ask three questions, choose the form of the deliverable and list the difficulties. The framework I apply systematically.
First, see where the problem lives
Before any app idea, I spend a few hours in the places where people actually talk about their problems. Not to validate my idea, but to listen to how they phrase it in their own words.
My hunting grounds:
- Reddit: topical subreddits, keyword searches in the domain
- Specialised forums: often less noisy than Reddit, and deeper
- Facebook groups: useful for mainstream topics (health, parents, pets)
- X and LinkedIn threads: good for pro topics, less for daily-life problems
- 1 and 2 star reviews of existing apps in the space: a goldmine for frustrations
What I note during this phase:
- The exact vocabulary people use to describe the pain, to reuse later in copy
- The workarounds they already rely on (Excel, sticky notes, another tool repurposed)
- The features asked over and over in competitor reviews
- The emotional intensity of the problem (mild annoyance vs. real exasperation)
If I find no one complaining, that's a signal. Not a veto, but a signal.
The Painkiller, Vitamin, Candy grid
Not every app relates to a need the same way. I use three buckets to position myself:
| Type | Promise | Recurrence of the need | Willingness to pay |
|---|---|---|---|
| Painkiller | "I hurt, make it hurt less" | Strong, sometimes blocking | High and fast |
| Vitamin | "it'd be nicer if…" | Moderate, you can live without | Variable, requires conviction |
| Candy | "ha, that's fun" | Low, mood-dependent | Very low, ads or freemium |
Knowing the bucket isn't a value judgement, it's a strategic compass. You don't launch a Painkiller the way you launch a Candy.
The three questions that decide
To know which bucket I'm in, I ask three questions:
- Are people already searching for this kind of app? (Google searches, Reddit posts, similar apps)
- Are people paying for similar apps? (proof of an existing market)
- Can I explain what it does in one sentence? (clarity of the promise)
The scoring reads as a grid:
| Profile | Q1 — searched | Q2 — paying | Q3 — clear sentence | Score | Read |
|---|---|---|---|---|---|
| Painkiller | ✓ | ✓ | ✓ | 3/3 | Real pain, active market, clear promise |
| Vitamin | ✓ | ✗ | ✓ | 2/3 | Likely usage, business model still to invent |
| Candy or unclear | ✗ | ✗ | ✗ | 0/3 | No pain, no market — reframe or drop |
Three yes, it's a Painkiller. Less, it's a Vitamin or a Candy. Not a problem, but the strategy changes: a Vitamin needs more marketing to exist, a Candy needs mass distribution or nothing at all.
For a Painkiller: do ONLY the thing that solves it
When you've got a real Painkiller, the biggest mistake is to bloat it. The temptation is strong:
- "What if we added a team mode?"
- "What if we also built an analytics dashboard?"
- "What if we integrated with Slack and Notion?"
Every feature that isn't the antidote to the main problem dilutes the promise, slows shipping and blurs the pitch. The customer came to make the pain stop. Anything that doesn't help is noise.
If I remove this feature, does the pain come back? No, then it's noise, I cut it.
How to compete when the market already exists
If Q1 and Q2 say yes, it also means there are competitors already. Five levers I review, in the order where I can win:
- Better UI / UX: many incumbent apps are ugly, slow, mobile-hostile. A frequent way in.
- Sharper features: not more, better. An app that does the two things that matter better than anyone wins.
- Fairer pricing: either cheaper, or a clearer model (no hidden usage, no aggressive tier jumps).
- Iteration speed: shipping a useful update every week makes a visible difference. Incumbents often move at quarter pace.
- User listening: replying fast, picking up suggestions, staying accessible. Big players have stopped doing this.
How those levers chain together:
| Step | Action | Outcome |
|---|---|---|
| 1. Pick | 2 or 3 coherent levers (don't spread thin) | A sharp positioning promise |
| 2. Build | Ship that differential against incumbents | A measurable initial edge |
| 3. Close the loop | Patch → measure → adjust, every week | The edge widens instead of eroding |
No single lever is enough. Two or three in alignment are enough to exist.
What form to ship?
The form depends on the moment of use and acceptable friction. My decision tree:
| Form | When to consider it | Install friction | Distribution |
|---|---|---|---|
| Web app | Occasional use, shared, accessible anywhere | None | URL, SEO, sharing |
| Browser extension | Grafts onto existing web usage (Gmail, GitHub) | Low | Chrome / Firefox stores |
| Mobile app | On-the-go use, sensors (camera, GPS) | Medium (App Store) | iOS / Android |
| Desktop or CLI | Pro, performance, scripting, automation | High | Homebrew, .dmg, .exe |
| Plugin (Figma, Notion, n8n…) | Usage already lives inside a platform | Low | Platform marketplace |
Simple rule: ship where the problem already lives. If the pain shows up in the browser, don't build a mobile app. If it shows up in the field, don't build a web app.
Drawbacks and difficulties to anticipate
Before writing the first line, I honestly list what can break. Four buckets:
On distribution
- Stores (Apple, Google, Chrome) have rules, delays, rejections
- SEO takes months to bed in, even on an excellent product
- A niche Painkiller is hard to find, you have to fetch users one by one early on
On the tech
- A third-party integration (Stripe, Calendly, n8n, a store API) can break any time
- The target platform can change its rules (Manifest V3, API restrictions)
- User data, the moment it exists, triggers GDPR, backups and security
On the economics
- LLM API costs can eat the margin if you don't optimise the prompt
- A poorly calibrated freemium converts at 0.5% and never pays for hosting
- Paid acquisition rarely pays back below a 50 € average basket
On the human side
- Customer support eats time from the first hundred users on
- Negative public feedback always shows up, you have to be mentally ready
- Solo, boredom or doubt on a 6+ month project is harder than people expect
Naming these difficulties BEFORE starting protects me from bad surprises and helps me size scope better.
Summary
The framework boils down to five steps:
- Go see where the problem lives (Reddit, forums, competitor reviews)
- Classify into Painkiller, Vitamin or Candy
- Answer the three questions to confirm
- Choose the form closest to the moment of use
- List the likely difficulties before coding
If at the end I have a 3/3 Painkiller with a one-sentence promise and an obvious form, then I open the editor. Not before.