DEV Community: Dan Liang

A fair price doesn't make a plan the right fit

Dan Liang — Mon, 02 Nov 2026 13:40:17 +0000

Your software has paying customers, but revenue hasn't grown in a while. You could work on SEO, improve the website, or revisit pricing. You only have the time and budget for one or two of those.

If you're considering pricing, first separate two jobs: changing the price of the existing plan, and designing a plan for teams. Those projects don't necessarily deserve the same priority.

A survey about the existing plan's price can inform the first decision. It doesn't answer whether teams need a different plan.

Revenue at Tom's Planner, a Gantt chart tool, had been flat for a few years. Growth consultancy DemandMaven worked with founder Tom to send a price sensitivity survey to more than 100 active users.

Tom said his pricing seemed to be in the right range. That gave him one less thing to consider.

Yet developing a team plan was still one of his priorities for the coming year. That work included both features and pricing.

A customer can be happy with what they pay to use a product on their own, then struggle to find a suitable plan when they want to bring in colleagues. Changing the price they pay today and designing a plan that works for their team are different pieces of work.

When reviewing a business that's stalled, I separate those decisions. Then I look at how customers use the product, what came up during purchase discussions, and why they didn't buy or renew. Those records help show which job deserves attention first.

Suppose individual users are renewing, but teams aren't buying. Some teams have tried the collaboration features and need them, but the minimum seat purchase is larger than they need.

If usage records, purchase discussions, and reasons for walking away repeatedly point to that issue, the team plan is worth investigating first. The question is how to offer those teams a suitable plan. It doesn't necessarily call for changing everyone's price.

But if teams aren't buying because the product doesn't support the way they need to work together, there's a feature gap to address. A lower price won't let them do work the product can't support. "Too expensive" alone doesn't tell you which problem you're dealing with.

The existing plan may be able to wait. Suppose your next round of work is still aimed mainly at the customers covered by the survey. Their purchase, renewal, and usage records don't suggest that price is preventing purchases or renewals. Another problem you've already identified is causing customers to leave. In that situation, a broad price change may not deserve to go first.

That doesn't make the current price optimal or rule out room to charge more. It means you don't yet have a strong enough reason to spend your limited capacity on a broad price change ahead of the other work.

You still need records from customers who left, people who never bought, and customers with a new use for the product. Without those, you can defer a broad price change. You haven't ruled out a pricing problem.

You might leave the current price alone while making the team plan a priority. Before deciding what comes next, be clear about the job: changing the price of an existing plan, or designing a suitable plan for teams?

More services. Still the same clients.

Dan Liang — Sun, 01 Nov 2026 12:54:47 +0000

Suppose you run a small web agency. Projects are ending, and new work hasn't come in. You're considering training the team to offer AI workflow services, starting with past clients.

It's a reasonable place to start. They know you. They've bought from you. What you learned about their businesses while building their websites may still be useful.

But what do you want that investment to buy? More work from existing clients, or revenue that no longer depends on just those few businesses?

That changes how much you can justify spending on the new service.

A Promethean Research interview roundup describes Fountain City's experience. Work from existing clients was expanding, while new-client acquisition received less attention. Then a major client of six years completed its digital transformation project. The engagement ended, leaving a substantial revenue gap.

Client projects end. Six years together doesn't mean another six years of work are waiting.

Back to the web agency. Suppose the AI service sells, mainly to the same clients. Revenue may recover. But if one client cuts its overall budget for outside services or stops working with you, both website and AI revenue may be affected.

More services. Still the same clients. You may earn more from them without gaining another group of clients.

If the revenue gap came from projects ending without new clients coming in, how much the new service can replace depends on the work those remaining clients can buy. When I review a stalled business, I look at project revenue alongside why the work ended. Can another project from the same client fill the gap, or do other clients need to replace that account?

A list of past website buyers can't answer that. An AI service needs current work to discuss, and the person buying it may not be the person who bought the website.

If that work exists, you can reach whoever buys it, the return after delivery costs and the additional investment is worthwhile, and someone can deliver it, expanding the relationship may make sense. It could even fill the immediate gap. You don't have to fix the whole old business first.

But restoring revenue from the same clients leaves you dependent on them. Selling those extra projects doesn't mean the next clients are lined up.

If you want the AI service to bring in new clients, you still need to work out where they are and how to enter their buying process. Training builds delivery capability. It hasn't built that route to new buyers.

With specific projects to discuss with existing clients, you can judge the training and delivery investment against that work. If you're counting on the service to replace ending projects over time, but have no route to new clients, you can't treat the whole expansion as if it already has a market.

Adding a service can be good business. Be clear whether you're investing in more work from existing clients or also giving the next clients a way in. Training isn't the whole cost of both.

Two weeks to ship. Then what?

Dan Liang — Sat, 31 Oct 2026 13:38:40 +0000

A new feature can be live in two weeks. After that, it still needs two days of maintenance and support every month. If it really brings in customers who are ready to pay, those two days may be worth it. The question is: who will do the work?

You've built the product. You've tried promotion. Revenue still isn't where you need it to be. Add features, redo the website, run ads—each option sounds reasonable. You only have the money and the people for one or two.

I've built game and blockchain projects myself, and I've felt how difficult product promotion can be. When several moves all look useful, the hard part isn't making a list. It's deciding where the next dollar goes.

That's when it's easy to compare only the visible cost: how long something takes and what it costs to launch.

Two weeks of development is easy to see. The two days every month don't end at launch. If you keep doing the work, that's six more days over the next three months.

Those days come out of the same calendar where you're already trying to meet potential customers. The feature may ship while the customer-acquisition problem stays exactly where it was.

Those six days belong in the cost. If suitable customers are willing to pay for the feature, and you can staff the ongoing support, it may be a good investment. A higher development cost doesn't automatically make it the worse choice.

But if the reasoning is only, “More features should make it easier to sell,” and you're the only person available to maintain them, “only two weeks” has left out the price. You can reduce the scope and make fewer promises. Or wait until the work has an owner. Whether the money should go to ads is a separate question.

Tom's Planner, a Gantt-chart planning product, offers a useful reminder. In a DemandMaven case study, its founder was looking at several growth opportunities while trying to keep the team small. He said he could put five things in motion at the same time, but then he would be trying to manage them for years to come.

Starting five things and carrying them for years are two very different demands on the same small team.

The same applies to a new channel. Opening an account or putting up a page can be quick. Continuing to write, follow up, and deliver on what you promised is work someone has to keep doing. Maintenance and operations aren't bad. Treating them as a problem for after launch is what makes an investment look cheaper than it is.

So the next time someone says, “It's cheap. We can have it done quickly,” I would ask one more question: what happens after it's done?

List the ongoing work. Decide who will own it and what it will displace. If nobody can carry it right now, shrink the plan or pause it. If someone can carry it and the customer benefit is worth it, ongoing work is not a reason to abandon the idea.

This still won't tell you whether the next dollar belongs in the product or in finding customers. It won't tell you whether the whole direction deserves to continue. It will keep one false bargain out of the comparison: something can be cheap to start and still have no one to carry it.

Orders Are Down. Should You Lower Your Hourly Rate?

Dan Liang — Fri, 30 Oct 2026 13:08:06 +0000

You charged 100 an hour. Now you're considering 80 because an empty calendar earns nothing.

A lower rate might bring work back. Fair enough.

In our work with founders whose businesses have stalled, we review decisions like this. Before changing it, I ask what the client means by “too expensive.”

Sometimes the project is worth doing and the budget is simply short. A lower rate may close that gap.

Sometimes the client has not decided whether the work is worth doing, or what the total bill will be. In that case, changing 100 to 80 does not explain what the hours will achieve or where the final bill may land.

If the concern is that the hours will keep expanding, clarify the scope, estimated hours, and deliverable before offering an even lower number.

The useful question: what specific piece of work is this lower rate meant to make more likely?

Fewer orders explain why you feel pressure to cut your rate. They do not, by themselves, give the client a reason to buy.

Industry data reflects the pressure. The 2026 Freelancer Study for the DACH region found that 9% of respondents planned to lower their hourly rate; among them, 61% cited a lack of orders. The study records an intention to cut rates; it does not show whether orders returned afterward.

Consider this. A client is ready to buy 10 hours of work and has an 800 budget. At 100 an hour, the quote is 1,000; at 80, about 800. If the scope, hours, and budget are real, the lower rate has a concrete reason to help close that deal. It still does not guarantee a signed contract or payment.

But getting the work and improving your income are different questions.

Suppose you used to sell 50 billable hours a month at 100, for 5,000 in revenue. Orders fall and you sell 40 hours, for 4,000.

If those 40 hours can still be billed at 100 and a new client buys 10 additional hours at 80, total revenue becomes 4,800. That may help.

If every new quote is now 80, selling 50 hours again produces only 4,000.

The workload came back. The revenue did not.

If the old-rate work has already disappeared, the 4,800 calculation no longer applies. To get back to 5,000 at 80 an hour, you would need to sell 62.5 hours. That is arithmetic, not proof that those hours exist, and it is before costs.

“Give me a lower rate and I’ll send you more work later” is not revenue. Scheduled or agreed hours is more concrete, but it still has to be delivered and paid for. A one-time discount can become the starting point for the next negotiation.

The market may genuinely have moved to a lower price. Then the service’s economics need another look. One discount will not fix a long-term lack of orders.

Lowering your rate is not automatically a step backward. When cash is tight, a lower-priced job can be worth taking.

The danger is dropping every quote before you can say what extra work the lower rate is meant to bring.

Why Aren't Potential Customers Replying to Your Emails?

Dan Liang — Thu, 29 Oct 2026 12:30:00 +0000

You've sent ten emails. Maybe more. No replies.

We hear this often when helping founders rethink a business that's stalled.

These people look like a good fit for your product. The company size is right, the work they do matches, and they seem to face the very problem you're trying to solve.

But the messages go out, and nothing comes back.

Send another, and you might become a nuisance. Walk away, and you wonder whether you're giving up too soon. Wait long enough, and even the product you believed in starts to look doubtful. Does anyone actually need it?

The hard part is wanting to change something without knowing what to change.

Hunter's 2026 report analyzed 31 million emails sent by its users in 2025. The average reply rate for initial emails in that sample was about 3%. Ten unanswered emails aren't enough to conclude that something is wrong with the product.

A message can go unseen. An address can be wrong. Bounces and messages sent to the wrong person are worth checking first. But even if the email arrived and they read it, the question remains: they have this problem, so why aren't they responding?

The same problem can mean different work

Say you've built a tool that automatically follows up on overdue invoices for independent consultants. Fewer payment dates to remember. Fewer reminders to write. It sounds useful.

Contacting consultants who've been paid late makes sense.

But "chasing payment" can mean very different things in someone's working day.

One consultant occasionally gets paid late. An email usually sorts it out. It's annoying, but not annoying enough to justify setting up another tool. A spreadsheet, calendar and inbox do the job well enough.

Another can't collect the final payment because the client says the last round of revisions isn't finished. They need to agree on whether the work is complete. An automated reminder can arrive right on time without bringing the money any closer.

A third is short on cash. They need to find whoever can authorize payment and establish whether it will arrive this week. "Spend less time chasing invoices in future" and "Will this money arrive by Friday?" carry very different weight right now.

All three might agree that chasing payment is a pain. The same invoice tool would be useful to them in very different ways, if at all.

This is where the mismatch can begin. We describe their need as "late payment." They are dealing with forgotten invoices, disputed work or a payment waiting for approval.

We haven't invented the need. We've treated several different problems as one.

Even knowing that someone is under pressure doesn't close that gap. Urgency can push someone to look for a new approach. It can also leave them with no room to evaluate one while they deal with the immediate problem. What matters is which piece of work we can actually help move forward.

So an unanswered email may have more behind it than unconvincing copy. The recipient may not see how this conversation connects to what they're trying to get done.

What can the next email say?

If all we know is that they're an independent consultant, we don't yet know which payment, if any, they're worried about. We can keep exploring. The next conversation could be about where payments tend to get stuck, without assuming that automated reminders are what they need most.

If they've recently written publicly about checking invoices one by one and sending reminders every month, we have a specific use for automation to discuss. The next message can pick up that piece of work without introducing the whole product again.

If we've already spoken, they asked for a proposal and we agreed to talk on Friday, silence on Monday is different again. We can follow up on that agreement. They may have missed the message, or their plans may have changed. A reminder can serve a purpose without a new feature or discovery attached.

We don't know who will reply in any of these situations. But what we already know does change what the next message can reasonably say.

And having something relevant to say still doesn't guarantee an answer. A clear no means we stop. Repeated silence, with nothing specific left to pursue, can be a reason to put our time into other conversations. A reply or a change in circumstances can give us a reason to return.

Putting one conversation aside doesn't require us to write off the product.

We've spent a lot of time building something. Of course we want people with the problem to hear us out. That urgency is understandable.

But they may be trying to collect a disputed final payment while we keep explaining how to send fewer reminder emails. Both sides are taking their work seriously. We just haven't found the same thing to talk about yet.

Before sending another email, I'd want to understand where that payment is stuck.

Where Do You Find Your First Customers?

Dan Liang — Tue, 27 Oct 2026 13:27:58 +0000

You know roughly who your product is for.

Developers. Agencies. Small-business owners.

Ask where to find them and someone says LinkedIn. Someone else says Reddit. Now you have another platform to search. You still don't know who to approach.

A customer description gives you a group. The work those people are trying to finish can give you somewhere to look.

A question that led to a customer

In a Mixergy interview, Zapier co-founder Wade Foster explained how he found Andrew Warner, who became the company's first customer.

Foster was looking for people who needed help connecting software. He came across a question Warner had posted on Web Applications Stack Exchange:

"How can I auto-import contacts from PayPal into Highrise?"

PayPal had his customers' addresses. He wanted them in Highrise, his contact-management software.

A person. Two tools. A job he was struggling to finish. Foster had something concrete to follow.

By the time Foster got in touch, Warner no longer needed that particular integration. Their conversation uncovered a related need: moving email addresses from a Wufoo form into AWeber, his email-marketing tool.

The question helped Foster find him. The conversation established what he still needed.

What would you look for in your market?

Say you offer returns automation for small online stores.

Search for "small online-store owners" and you can collect plenty of profiles. Which one do you approach? Why that one?

Ask how stores handle returns today, and the search has somewhere to go.

An operator may be discussing refunds in a support-tool community. That gives you a discussion to read and, where appropriate, contribute to.
An order-management consultant may show the kinds of stores they serve. That helps you learn which businesses do this work and who already helps them.
An industry event about returns may offer a way to meet practitioners.

You can explain why you're looking in each place. That's already better than trying another platform because the last one disappointed you.

A name still leaves questions

Of course, you have to check what you find. The discussion may be old. The group may be full of other sellers. The person doing the work may have no authority to buy.

Finding someone isn't permission to pitch. You can listen or contribute in a community without treating its member list as an invitation to send automated messages. A service provider isn't automatically a referral partner.

You've found a possible way in. Whether contact is welcome, and whether the person needs what you offer, still need checking.

Give yourself something to look for

Look at your customer description. If all it gives you is an industry or a job title, add a piece of work that person is trying to finish.

What do they use? Where do they ask for help? Who already works alongside them? Follow a connection that could lead to an actual person.

Sometimes the work leaves little public trace. An introduction, an industry association or an in-person event may be the sensible route. Finding that out beats another week of switching platforms without knowing why.

Your first customers may never gather in one room marked "your market."

Look at what they're trying to get done. The work can tell you where to look.

They have the problem. So why won't they give you feedback?

Dan Liang — Mon, 26 Oct 2026 12:30:00 +0000

You send out invitation after invitation, asking potential customers for feedback. Not a single reply.

You need feedback before spending another month on the product. Do you change how you reach people, or go back and change the product?

"Could you take a look and give me some feedback?"

A small favor. At least, that's how it sounds when you're asking.

But a useful answer can mean learning an unfamiliar tool, explaining how they work today, then figuring out what you should change. You're asking them to help shape a product you hope to sell them.

That is a lot to pack into "take a look."

Your product might save them time later. Giving you feedback costs them time now.

Someone can be drowning in admin and still have no appetite for another tool to evaluate. Their problem is urgent. Helping you doesn't automatically join the queue.

The conversation needs a reason of its own.

Suppose you're building a tool for agencies that spend too long chasing client approvals. Come prepared to discuss a tradeoff: keep reviews in email, where clients already work, or move them into a portal that collects comments in one place but gives clients another place to check.

Now there's something for an agency owner to think through about their own business, whether or not they ever buy your tool.

And yes, you still want to learn from them. Say so. But do some of the thinking before asking them to do theirs. Give them something worth discussing.

Before treating silence as a verdict on the product, look at what you asked them to take on. Another feature may leave that request exactly as it was.

Your need for answers is real. It isn't their reason to say yes.

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."