I appreciate people who want to support my work. Sometimes that support is exactly what gets a business started. A friend buys the first copy, shares the launch, or gives an unfamiliar product a chance because they trust the person behind it. Some of those people become your best customers.

But I want to get through the noise of encouragement quickly and find the people who would pay because they actually want what I am making.

Buy it because you want what it does. Read it because you want to know something. Use it because it makes a part of your life better. If the work fails to do that, I need to find out.

A purchase made mainly to encourage me can postpone that discovery. You want me to succeed. I get a payment notification. It becomes easy to avoid the awkward question of whether I made something you actually wanted.

For an afternoon, everybody wins.

Then I make business decisions with the answer I imagined you gave me.

This is what bothers me about “support my work” becoming the main pitch for a product. It asks the buyer to think about the person who made it. How hard they worked. How much courage it took to launch. How badly they need this to succeed.

All of that may be true. It still leaves the buyer’s life almost completely out of the conversation.

What did the payment tell you?

Imagine you build an invoicing tool and share it with your friends. A few pay immediately. They congratulate you, repost the announcement and tell you to keep going.

Good people. A good day.

But suppose several of them don’t send invoices. They have salaries. The tool has nowhere to fit into their week. They bought because you built it, and they wanted to do something kind.

The money is real. You can spend it. The trouble starts when you interpret those purchases as evidence that you have found customers for an invoicing business.

Now imagine a freelance designer buys it, sends an invoice, gets confused by the payment status and messages you about it. Next week, she sends another invoice. She asks whether she can reuse a client’s details because entering them again is annoying.

There is something to work with there. You can watch where the product helps, where it wastes her time and what she keeps returning to do. Her questions come from having somewhere to use the thing.

She might also be your friend. That changes nothing about the value she is getting.

The mistake is treating everybody close to you as validation, or dismissing everybody close to you as biased. You have to look at what happens after the congratulations.

In No more subsidy, I wrote about charging for The African Engineer. I stand by that. Writing is work, and offering it for sale is an ordinary business decision.

Charging also gives me a responsibility. I have to keep asking whether readers are getting something worth their money. An early purchase is encouraging. It cannot answer every question about the publication’s future. The next piece still has to earn its place in someone’s day.

Give people something to buy

African builders, we need to be careful about making solidarity carry the whole sales pitch.

“Support an African founder” tells me something about you. What am I buying? What will I be able to do with it? Why would I choose it over whatever I already use?

Take a hypothetical inventory app for a shop owner. Tell her how it helps her notice stock running low before a customer asks for it. Show her how to enter a delivery without turning the evening into another shift. Let her try it with the stock she actually sells.

Then pay attention. Perhaps the app saves her time. Perhaps her notebook is easier. Perhaps the person who receives deliveries has no reliable access to the device you designed around. Those are useful things to discover, even when they are inconvenient for your beautiful demo.

“Please support me” makes it easier to walk away with encouragement and miss all of that.

The offer does not always have to involve saving money or removing an expensive problem. People buy music because they enjoy it. They pay for stories, beauty, a sense of belonging, something that helps them understand themselves. Those are perfectly good reasons to buy. A product doesn’t need to resemble accounting software before it deserves a business.

But the buyer should be getting something they want. Make that clear enough for them to choose it without having to worry about disappointing you.

And let them decline.

Some people cannot afford what you charge. Some have other priorities. Some would buy if the payment method worked for them, or if the pricing matched how often they needed it. Their refusal is not a character flaw. It is certainly not a betrayal of the ecosystem.

You can investigate the offer without demanding an explanation of their finances. Change the packaging where it makes sense. Find a better audience. Fix a confusing pitch. Keep your price if that is what the business requires. Just don’t turn the checkout into a test of loyalty.

Find out what happens next

There are better questions than “Would you support this?”

Ask how someone handles the problem today. Ask about the last time it happened. What did they try? What worked badly enough that they are still looking?

Strategyzer’s guidance on customer discovery makes this distinction useful: learn from specific past actions, then move towards experiments that require people to do something. A nice opinion costs very little. An actual purchase tells you more, although you still need to understand what the person was buying.

Once they have paid, watch whether they get the promised benefit.

For a recurring tool, that might mean using it again when the job comes around. For a publication, it might mean reading, finding the work useful and choosing another issue. A course might do its job so well that the student finishes and leaves. You don’t need to keep someone trapped in lessons forever to prove you taught them something.

The timing matters too. A product used for an annual task should not be judged as if it were a daily messaging app. In YC’s discussion of retention, the point is to measure value on a timescale that fits the product. The useful question is whether people return when they have a reason to, or achieve the outcome they came for.

You also have to go and find those people. Please don’t post one link, receive three polite replies and conclude that nobody wants what you built.

Paul Graham’s Do Things that Don’t Scale describes the work of recruiting early users yourself and helping them get started. There is no shame in doing that. A good product can need explanation, trust and patient onboarding before somebody gets its value.

Use your network. Ask a friend who doesn’t need your product to introduce you to someone who might. That introduction can be more useful than another purchase from somebody who will never open it.

There is also a place for simply funding work you want to exist. I maintain open-source software. I am not going to pretend every valuable contribution should sit behind a checkout. GitHub Sponsors exists so people and companies can help fund the maintainers of software they depend on, including software available freely to everybody else.

Art and independent publishing can have patrons too. Someone can deliberately pay so other people get to benefit. There is nothing embarrassing about that arrangement when everybody understands it.

What worries me is asking for a favor, receiving one and then telling myself I have proved the product works.

Be grateful when people believe in you. Their kindness may give you time to find your feet. You don’t have to insult the people who helped you start in order to get serious about what comes next.

Start asking early, while that encouragement is still giving you room to learn. Who used it? Who got the promised result? Who would choose it again? You want those answers before you spend the next six months building for people who were only trying to cheer you on.

You need an answer to the question their generosity cannot settle for you.

If they were not trying to help you, would they still want what you made?

I want to build work that can survive that question.