Build for Recurring Usefulness and Earned Trust

Illustration accompanying the original painkiller-versus-habit product essay

Reviewed September 5, 2026: Originally published as “Painkillers Aren’t Enough: Why Your Software Product Needs to Solve a Repeated, Addictive Problem.” Revised to distinguish recurring usefulness from dependence, and to recognize viable one-time purchases and occasional-use products. The original address and publication date are preserved.

“Don’t build a vitamin. Build a painkiller.” It’s familiar startup advice: solve a problem people have a reason to address.

That is a useful starting point. It leaves another question unanswered: when will the customer need the solution again?

For a product intended to serve an ongoing workflow, recurring usefulness matters. People should return because the work needs doing and the product helps them do it well. Addiction and dependence are poor design objectives.

Match the Business Model to the Need

A one-time solution can be a sound business. Migration tools, specialist utilities, and project-based products can deliver substantial value without becoming daily habits. Their economics need to work for the way customers buy and use them.

Likewise, recurring use does not automatically justify a subscription. A product purchased once can remain useful for years. An occasional task may justify a service, a usage fee, or another arrangement.

The question is whether the value delivered, acquisition cost, support obligations, and price form a sustainable business. Frequency is part of that assessment.

Look for Pain, Frequency, and Friction

I find three questions useful when examining a product idea:

  1. Pain: What consequence makes the problem worth solving?
  2. Frequency: When and how often does the customer face it?
  3. Friction: What makes the current approach slow, costly, confusing, or unreliable?

These are prompts for investigation, not a formula that guarantees product-market fit.

Consider onboarding a new employee. Paperwork, access, equipment, and introductions need coordination each time someone joins. A useful product could make those steps clearer and reduce missed work.

Its value follows the hiring cycle. A customer who hires twice a year may need it twice a year. Asking that customer to open a dashboard every morning would add activity without improving the outcome.

Earn a Place in the Workflow

A product earns trust by doing the expected job reliably, preserving useful context, and making the next step easier.

That can mean becoming part of a regular routine. It can also mean quietly handling work in the background or being ready when an infrequent event occurs. Less time in the interface can be a sign that the product is working well.

Customers should be able to understand what the system does, retrieve their information, and leave without artificial obstacles. Retention built on a useful service is a stronger objective than retention manufactured through confusion or lock-in.

Find the Trigger Moments

Look for the event that creates the need:

Design around that event. Provide the context and controls needed to complete the work, then let the customer move on.

A reminder is useful when it serves a real obligation. A notification sent only to pull someone back into the product deserves more scrutiny.

Test the Outcome

Novelty can attract a first look. Continued use needs a reason that survives the demonstration.

Ask customers what became easier, what errors were avoided, and what work still requires a workaround. Check whether they return when the relevant need recurs. For an annual task, tomorrow’s login count tells you very little.

For background software, look at the work completed and the quality of exceptions surfaced. For a one-time tool, look at successful completion, customer satisfaction, referrals, and whether the sale supports the cost of delivery.

Choose measures that reflect the job the customer hired the product to do.

What Should You Build?

Start with a specific customer and a consequential problem. Understand its frequency, examine the current workaround, and test whether your approach produces a worthwhile improvement.

Then choose a business model that fits the value and the cost of providing it. Make adoption straightforward, keep promises, and earn the next purchase or return visit.

The product worth keeping is the one that continues to help when it is needed. Sometimes that means every day. Sometimes it means staying out of the way until the next important moment.