DEV Community: Dan Liang

More users or clearer feedback: which product should you keep building?

Dan Liang — Thu, 22 Oct 2026 15:05:01 +0000

One product has more users, but the feedback is mostly "looks useful."

The other has fewer users. But a few are willing to show you how they use it and try your next update.

You only have time to focus on one this month.

The usual answer is to pick the one with users already asking for changes. Or the one with the larger market, stronger technology, or the shortest path to launch.

Those comparisons still matter. But they don't tell you how hard it will be to keep improving after launch.

On Hacker News, a founder was deciding which of four tools to open-source first. Two were already built, and one was getting some users through ChatGPT. The founder said they weren't talking to enough customers, and improvements were coming slowly after the initial build.

If you can build the first version but then struggle to improve it, there's another cost to compare: how much work it takes to find out what to change, every time.

A signup, a compliment, or a feature request can show interest. It doesn't necessarily show you how the product fits into someone's work, where they get stuck, or whether the last update helped.

If a lack of useful feedback is what's slowing you down, the product with fewer users may deserve more of your time. In the opening example, some of those users are willing to show you their work and try an update. That gives you a chance to follow up on a change, instead of starting each round by finding new people and explaining everything again.

That doesn't make it the bigger opportunity. Reliability, maintenance, licensing, distribution, or willingness to pay may matter more. If one of those is holding you back, better access to feedback may not change which product deserves priority.

I'd compare more than the effort needed to launch each product. I'd also compare how much work it takes to get useful feedback for the next change, and the one after that. An easy first build can still leave you starting from scratch to find out what to fix every time.

People Agree the Problem Is Real. Should You Spend Another Month Building?

Dan Liang — Wed, 21 Oct 2026 12:30:00 +0000

People agree the problem is real. Your offer still isn't selling. Should you spend another month building?

A freelancer sells a fixed-price service that sets up a repeatable onboarding process for small agencies.　

Several agency owners agree that onboarding is messy, repetitive, and costly. They say the service sounds useful.

Those are real signals. The problem is recognizable. It may even be expensive.

They still do not show that an agency will choose this service over its current workaround, pay for it now, or make room for it this quarter.

That gap matters because the next action often follows the wrong conclusion.

The freelancer hears "the problem is real" and spends another month on better posts, a clearer demo, or more features. More people then agree that the problem exists.

The evidence looks stronger, but it is still evidence about the problem, not the offer.

The usual answer is reasonable: perhaps the offer is fine and needs more reach, sharper wording, or a buyer with more urgency and budget.

Sometimes that is exactly right. If the right buyers have not seen or understood the offer, more reach or clearer explanation is still useful.

But if the next investment only produces more agreement that the problem exists, it has not tested the offer. It has not told you whether buyers would replace their current workaround, at what price, with what priority, or when.

Before approving the next month, ask what the new work is supposed to change in the buyer's decision.

A stronger signal might be a buyer comparing your offer with what they do now, discussing price or timing, asking what it would take to start, paying for it, reusing it, or explaining what would make them choose it.

These are examples, not a checklist.

If none of that has happened, call the result what it is: evidence that buyers recognize the problem and may care about solving it.

Do not call it proof that this offer deserves another month of building.

The decision is not:

"Did we learn anything?"

It is:

"Did this investment make a buyer more likely to choose this offer, or did it only help more people agree with the problem?"

That is the distinction between validating the problem and validating the next commitment.

If buyers are already comparing price, alternatives, and timing, or have paid and reused the offer, this judgment is too narrow. The bottleneck may be reach, trust, timing, or delivery instead.

Your service isn't selling. Do you need a bigger audience first?

Dan Liang — Tue, 20 Oct 2026 12:30:00 +0000

Imagine a freelancer rewriting another post because nobody has asked to buy their service.

For a fixed price, they automate client onboarding for small agencies: collecting client details, sending reminders and setting up the project. People say it sounds useful. So far, that hasn't led to a discussion about hiring them.

Has an agency owner had a fair chance to consider the service if hardly anyone sees the posts?

So the next week goes into a better opening, a clearer example, a sharper description of the problem.

The reasoning makes sense. Better posts could reach agency owners who need the work done. Rewriting is also something the freelancer can do themselves. Getting a buyer to respond depends on someone else.

But giving the service a fair chance has started to mean getting the account to take off first.

They now have another job: building an audience they hope will eventually bring inquiries. While they work on that, they still have no concrete buying feedback to guide changes to the service or its price.

An agency owner needs to understand the service and trust the person delivering it. An introduction from someone they already work with could help build that trust.

An owner who's still chasing client details by email could weigh the fixed-price setup against continuing to do it manually, even while the freelancer's posts reach very few people.

Finding someone willing to make that introduction and earning the owner's trust would take work, especially without an existing network. It might not lead to a conversation, let alone a sale. But building an audience wouldn't be the freelancer's only route anymore.

I'd keep publishing and put some of next week's editing time into getting a relevant agency owner to consider the paid service. The conversation has to be about the work and the fee, not about how interesting the posts are.

The service may still need changing. The price may be wrong. Those questions don't have to wait for the account to take off.

Your Monitoring Reports Are Accurate. Are They Still Worth Sending?

Dan Liang — Fri, 16 Oct 2026 12:10:00 +0000

Juan Camilo Auriti built a monitoring product that compared website properties across runs.

The reports were correct. 78% of them showed a delta of exactly zero.

His first response was technical: the change-detection thresholds must be too coarse. He spent about a month tuning them.

That was the wrong layer.

The product let someone audit a site, fix issues such as robots.txt or schema markup, and then watch those properties over time. Once the fixes were made, the site could remain stable in the dimensions being measured.

That is a successful first task. It is not automatically a reason to send a new report every week.

An empty recurring report can mean two different things:

The customer completed the job, and there was nothing new to act on.
The report did not carry a decision for the recipient in the first place.

Those interpretations point to different engineering and product work.

If the product promises assurance that a site remains stable, “no change” can be the result the customer wants. The question is whether the promise and cadence match that outcome.

If the product promises to tell the customer what to do next, increasing sensitivity does not solve the problem by itself. A report can detect smaller changes and still change no decision.

Juan Camilo Auriti described the turning point in his own monitoring product this way:

“The thresholds weren't the problem. The artifact was the problem.”

One commenter gave the problem a useful name: decisionless. Before sending a recurring artifact, ask: what decision does this change? Auriti agreed that this is a property you can check before sending, rather than an interpretation you make afterward.

This is why threshold work is so attractive. It produces code changes, diffs, and a number. The question “should this artifact exist at this frequency?” produces no diff and may force a change to the product promise.

For a report, alert, digest, or recurring audit, separate these questions before adding another feature:

Did the first task succeed so completely that the original problem stopped occurring?
Or does the recurring artifact fail to connect to a decision the recipient still has to make?

The first points to the promise and cadence. The second points to the artifact and its handoff into a decision. They are different failure layers, so they should not share the same next fix.

The figure is self-reported and the underlying query is not independently audited. This is not a rule that monitoring products should stop sending weekly reports. Stability may be the product. The point is narrower: an empty report is not enough evidence to choose between threshold work, delivery work, and a promise change.

When your recurring report comes back empty, what decision was the next issue supposed to change?

Nearly 200 ad clicks. Zero signups. Did the software fail?

Dan Liang — Wed, 14 Oct 2026 12:30:00 +0000

Octolens, a social-listening tool for tech brands, spent a little over €600 on a ChatGPT ad campaign. After two weeks, one ad shown in the US had brought about 25,000 impressions, just under 200 clicks, and zero signups.
During the same period, 10 people signed up after ChatGPT recommended Octolens in an ordinary conversation.

Founder Charlotte Schmitt reported both results. Her team checked the zero against OpenAI's conversion tracking and their own analytics. People clicked but didn't sign up.

Schmitt's interpretation was: "The recommendation has trust but an ad sitting next to it doesn't inherit that."

The comparison doesn't isolate trust as the cause. It was a small test, and those 10 signups don't establish a viable business. But treating the paid result as a verdict on the whole product would erase a difference that matters: people reached through another route did sign up.

You paid to put your offer in front of people under particular conditions. Those conditions are part of what you tested.

The failed campaign tells you something about that attempt. It doesn't make every way of reaching a customer equivalent to the one you paid for. Nor does the better result elsewhere tell you to keep investing indefinitely.

The stakes can be much larger. One founder on Hacker News put it plainly: "I am at a crosspoint now. I don't know if I should continue to work on my startup." They reported raising about $100,000, most of it spent on ads, travel, and accelerator workshops, and making about $4,000 in revenue. They still did not know whether to continue.

When you've paid for ads, outreach, or help finding customers and sales are still low, you have a bill, a disappointing result, and the same decision: spend again or stop the project.

You hoped a real attempt would settle the question. It can feel harder to leave when "maybe we didn't spend enough" is still available as an explanation.

When your own sales are low, "this attempt didn't sell" can become "this business can't sell." The opposite leap is just as tempting: "We haven't spent enough yet."

Both leap past the explanation you need before committing more money.
That is where a diagnosis earns its place. It clarifies what the customer was actually trying to buy, what your current offer gave them, and whether the gap is worth another round of time and money. It can recommend continuing, changing the offer, repositioning, or stopping, and explain why the evidence supports that recommendation.

Calling the result "a marketing problem" and handing you another campaign leaves that decision untouched. A useful diagnosis explains which part of the business the failed attempt puts in doubt, and whether the evidence gives you a reason to fund another attempt.

A disappointing result can justify stopping an attempt. Turning it into a verdict on the business requires an explanation.

Before committing the next budget, bring the failed attempt back into view as something specific: this offer, reaching people through this route, asking them to take this step.

The next payment deserves a reason stronger than "the last one didn't work."

Revenue is still low. Is the next fix progress—or another reason to stay?

Dan Liang — Mon, 12 Oct 2026 08:23:47 +0000

You've tried everything you could think of. Revenue is still low. Yet you still believe someone needs what you're building.

Then you spot another thing to improve. Continuing feels reasonable again. You haven't given this change a chance yet. What if this was the thing holding it back?

The next task gives you somewhere to put your hope.

It's a fair impulse. When results disappoint and you don't know why, a specific task feels better than the same unanswered question. You may be right about the problem. The fix may help.

Somewhere in that relief, the decision changes. You meant to decide whether the business was worth more of your time. Finding another improvement has turned that decision into a task: fix this first, then decide.

If the results are still weak afterward, another explanation is ready. The message needs work. You haven't reached the right people. Something else needs changing before the business has had a fair chance.

Each disappointing result can produce another task. If having a task is your reason to continue, even bad results can keep renewing that reason.

Suppose someone says your homepage doesn't make clear who the product is for. You can picture a better page. Walking away feels premature because you've found something fixable.

The observation tells you something about the page. That confusion explains the weak revenue only if it is turning away people who would otherwise have bought. Spotting vague wording hasn't shown that. Yet “I can make this clearer” can already feel like a reason to keep investing in the whole business.

A shallow diagnosis can reinforce this. It names a weakness and hands you a repair, but never explains what customers are trying to buy, what the current offer actually gives them, or whether the gap is worth fixing in this business. That is a better to-do list, not a decision.

A real diagnosis connects the customer’s desired outcome to what your business actually offers. It can recommend fixing, narrowing or repositioning the direction—or stopping—and explain why. Finding something to repair does not, by itself, justify more investment.

None of this makes you foolish for trying. Sometimes the next change does bring paying customers.

Without that judgment, waiting until there's nothing left to fix can turn a temporary commitment into an indefinite one.

If the diagnosis supports delivering what customers are trying to buy at a cost you can sustain, you have a reason to keep going. If the changes needed would demand more time and money than the business can justify, you have a reason to stop. The need can be real even when this business is no longer worth pursuing.

Something can still be fixable without being worth more of your life.

You've already shown you're willing to do the work. A diagnosis should help you decide whether this business is worth more of that work—and explain why.

Keep building your SaaS, or charge for the help customers ask for?

Dan Liang — Sat, 10 Oct 2026 15:36:46 +0000

RevFixr's early customers asked for pricing help before installing its SaaS. Helping them choose what to charge was a different job from helping them set up a pricing page.

Its founder, Tjitte Joosten, had built software for businesses' pricing pages. He described the requests this way:

our early customers kept asking for pricing support before installing our product.

I would put the weight on "before installing." If you treat that request as an onboarding problem, making the software easier to adopt looks like the next task. A product could help with that decision, but easier installation alone doesn't settle it.

Joosten says the team began offering pricing-strategy support as a paid service. It later compared the impact of the service with the product, dropped the software and became a pricing consultancy.

For a founder whose adoption has stalled, these requests can pull in two directions. They give you something concrete to work on and a reason to stay close to customers. At the same time, the requested work may support a business that sells your help rather than access to the tool. The same conversations can keep you close to customers without settling whether the software deserves the next development cycle.

This is where "keep going" becomes too vague. If each request for pricing advice becomes another reason to polish installation, you can keep doing product work without resolving the decision customers asked you to help with. Continuing to work on their problem and continuing to build the original software are separate commitments.

The case applies to help with a customer's pricing decision. A request to install a plugin or fix an integration can be ordinary setup work. The interview leaves the service's margins and repeatability unknown, so it doesn't establish that another founder should make the same switch.

More development time spent making pricing pages easier to install needs a reason tied to installation. Requests for help choosing prices support a different commitment. RevFixr retired the product and kept working on pricing; "stop building this" did not have to mean "stop serving these customers."

The Numbers Moved. The Next Decision Did Not Get Easier.

Dan Liang — Sat, 26 Sep 2026 05:07:30 +0000

One public founder post reported more than 35,000 content views and 1,500 visits to the site. Paid customers: zero. The founder asked what they were missing.

Another founder described two months of posting across seven platforms without a sale. Three weeks of Cloudflare data showed 380 page views, mostly from internal navigation and a page-builder's preview links. The Gumroad dashboard they had been watching no longer tracked the site's checkout, which had moved to PayPal. Cloudflare attributed none of those page views to a social-platform referrer.

These aren't two versions of the same failed funnel. One account describes a lot of attention with no purchase. The other shows how even the path behind the numbers can be misunderstood. Neither public post gives an outsider enough to decide what that founder should change next.

The work is visible. The zero is visible. What happened between the two may be much less clear.

If you've launched something and watched the activity rise without a sale, which part of the trail did you later realize you couldn't actually see?

What a Public $3K MRR Plateau Can—and Cannot—Show

Dan Liang — Mon, 07 Sep 2026 10:51:43 +0000

A SaaS reaches $3K MRR and then stays there. The next month looks much like the last. It is tempting to treat that flat line as a funnel problem and start changing the landing page.

The number does not tell us that. It shows that some customers paid. It does not show why they paid, whether they stayed, or whether the people arriving now resemble the first buyers.

A public post about a plateau is often missing exactly that history. We may see the MRR chart and a list of attempted changes, but not the customer conversations or the sequence of renewals and cancellations. Without those materials, calling the problem “conversion” or “direction” would be a guess.

The public collection I used in the earlier version of this article was a working set of mixed sources, not a representative sample of stalled SaaS products. Its counts cannot establish how common any cause is, including among companies around $3K MRR. I should not have presented its categories or percentages as a diagnosis readers could apply to their own business.

A flat MRR line alone cannot separate a conversion problem from a problem with the offer or buyer. What paying customers said and did after their first purchase would change the reading. Until then, the plateau is a reason to look closer, not a verdict.

The public research note now explains the limits of those sources. It is not a self-diagnosis guide.

Why a Waitlist Can End in Zero Sales

Dan Liang — Sun, 23 Aug 2026 10:14:44 +0000

Launch day can make an old signup count feel like a promise. People joined the waitlist, the product is available, and yet no one buys. It is a sharp gap, but the signup count alone cannot explain it.

Joining a list and buying are different actions. The first may mean someone wanted an update, liked the idea, or expected to look again later. A purchase asks more of them. That difference makes the waitlist useful as a record of interest, but a weak stand-alone account of what happened after launch.

It is also possible to overcorrect. Zero sales does not prove the audience was merely curious. A price change, a delayed launch, an unclear offer, or a product that asks for too much workflow change could produce a similar public result. The visible numbers do not separate those explanations.

The earlier version of this article presented three structural breaks and a prescribed interview-and-pilot sequence. That went further than the public evidence allowed. A waitlist can show that people noticed a promise; it cannot, by itself, tell us why they did not buy later.

This is a question raised by a launch result, not a verdict on what its founder should do next. The actual signup source, offer shown at launch, and later buyer behavior would matter before making that call.

Why a Compliment Is Not Yet a Buying Signal

Dan Liang — Sat, 22 Aug 2026 10:04:40 +0000

People say “Cool product.” They say they would use it. They ask to hear when it launches. Those comments can be sincere, but they are still records of interest, not proof that the problem is costly enough to change.

The distinction matters because a compliment is easy to give and easy to forget. A purchase changes a budget, a workflow, or a decision someone has been postponing. The two actions may sit next to each other in a founder’s notes while saying very different things about the business.

That does not make positive feedback worthless. It can show that the idea is legible, that the wording caught someone’s attention, or that a familiar problem has been named. It simply leaves the important part open: what the person did when the problem returned, and what they were willing to change.

The earlier version of this article turned that distinction into a one-conversation test, split answers into two types, and attached different product decisions to each type. That was more certainty than the public evidence supported. A warm answer can be useful context without being a reliable buying forecast.

A compliment raises a question about demand; it does not settle it. The missing customer history—what happened after the conversation, whether the problem recurred, and whether any commitment followed—would change the reading.

AI Tool Works Well But Nobody Uses It

Dan Liang — Fri, 21 Aug 2026 10:33:45 +0000

The demo is impressive. The output is clean. Early users say “wow.” Then they go back to doing the work the old way.

A good demo and repeat use are different outcomes. Without the actual usage trail and the task people returned to, the scene above cannot tell us whether the gap was product fit, workflow friction, reach, or timing.

A tool can produce a useful result and still fail to become part of someone’s working day. A manual step between the result and the finished task may be one source of friction, but it is not the only possible explanation. The task may be infrequent, the person trying the tool may not own the decision, or the original urgency may have passed.

The earlier version of this article turned that gap into three checks, a five-person test, and a set of fixes tied to each answer. That structure went further than the public evidence allowed. A clean demo tells us that the product can produce an output; it does not tell us why a particular person did or did not return.

This is a question raised by the adoption gap, not a verdict about the founder’s next move. A decision to fix, narrow, reposition, pivot, or stop would need the actual usage and customer materials.