How We Decide When a Product Is Done Enough to Charge For

Sorted Nexus had a paying customer before it had half the features we'd originally planned for it. That felt uncomfortable the first time it happened, in a way that took us a while to name properly. We weren't worried the product was broken. We were worried it wasn't finished, and those turned out to be two different concerns that we'd been treating as one.

Every subscription product we run had some version of this same moment: a point where the product could take payment, and a separate, later point where the product felt complete. Learning to charge at the first point instead of waiting for the second is one of the harder habits we've had to build on purpose.

"Is this done" is the wrong question, because a product is never actually done, it just keeps growing as long as it's alive. The question that matters is narrower: does this solve the specific problem we said it would solve, reliably, for the person who has that problem right now. That's answerable in a way "is it done" isn't.

For Sorted Nexus, that meant: can a small business owner create a quote, convert it to an invoice, and see whether it's been paid, without the process breaking or needing us to intervene. That's a much smaller bar than "a complete business admin platform," and it was also the actual thing the first paying customer needed solved. Everything else on the roadmap was real, but none of it was blocking that specific job from being done properly.

Our instinct, being risk-averse by nature, was to want more built before asking anyone to pay. That instinct is backwards for reasons we didn't fully appreciate until we'd shipped a few products. Every month a subscription product sits unpriced is a month we're guessing what to build next instead of hearing it directly from someone with money on the line. A free product gets feedback from people who have nothing to lose by using it poorly or not at all. A paying customer's feedback is a different signal entirely, because it's backed by the fact that they're still paying.

There's also a quieter risk in waiting: a product that never charges never has to prove it's worth paying for, so it can drift for a long time without anyone finding out whether the core idea actually holds up commercially. Charging early forces that question to get answered while the product is still small enough to change direction cheaply.

There's a shorter list than "finished," and it doesn't change much between products. The core workflow has to work end to end without us watching over it. Billing itself has to handle a failed card and a cancellation cleanly, because a subscription product that can take money but can't gracefully lose a customer isn't actually ready to charge anyone. And there has to be a real answer to what a paying customer gets that a free trial doesn't, even if that answer is simple.

None of that requires the product to be feature-complete. It requires the product to not embarrass us or the customer on the one thing they signed up for. Everything past that point is a reason to keep building, not a reason to keep the price tag off.

We've also gotten this wrong in the other direction, which is worth being honest about. Charging before the core workflow was reliable, rather than before it was complete, cost us more in refunds and trust than it saved us in early revenue. The distinction matters: an incomplete feature set is fine to charge through. An unreliable core workflow isn't, because that's the one thing the customer is actually paying to depend on.

The lesson we took from that wasn't "wait longer." It was "be precise about which gap you're tolerating." Missing features are a roadmap. A workflow that breaks under real use is a refund waiting to happen, and those two things get mistaken for each other more easily than they should.

We see the same false choice in almost every early-stage team we work with in technical consulting: founders who are either charging for something with a shaky core workflow, or sitting on something solid and refusing to charge for it because the feature list still feels short. Both mistakes come from measuring readiness by completeness instead of by whether the one job the product promises actually gets done.

Part of what we help clients do is draw that line for their own product: which gap is a roadmap item, and which gap is actually a reason a paying customer would ask for their money back. If you're sitting on a product and unsure which side of that line you're on, that's a conversation worth having through our services page before you either under-price the risk or over-delay the revenue.

"Done enough to charge for" has meant something different for every product we've shipped, and it keeps meaning something different as those products grow, because the bar for what a paying customer expects rises as the product matures. What hasn't changed is the test itself: does the core job get done reliably, right now, for the person who needs it done. Everything else can keep being built in public, in front of customers who are already paying, instead of in private, in front of no one.

If you're weighing whether your own product is ready to charge for, or ready to charge more than it currently does, we're happy to talk through where that line sits for your specific case. You can reach us through our contact page.