Launching my SaaS-only buyer database today on Product Hunt. Here's the bet I made on pricing.
Been heads down on Backchannels and we're live on Product Hunt today. Wanted to share the thinking, not just the link.
The problem I kept hitting: every B2B contact database is built for the entire economy. If you sell software, the data is something like 80% irrelevant, and you burn hours filtering out non-software companies to find your buyers. On top of that, you pay for a big annual subscription whether you use the data or not.
Two bets shaped the whole product:
Niche down hard on the data. Backchannels is 225k software decision-makers and nothing else. No manufacturers, no local businesses, just software buyers. Narrow data beats big data when your market is specific.
Kill the subscription. Instead of an annual contract, it's pay-per-contact at $0.08 each, and you browse every match for free before spending a credit. You only pay for data you've seen and want. This was the scary commercial call, because recurring revenue is the holy grail, but it removes the biggest reason people churn off data tools: paying for a seat they barely use.
It syncs to Salesforce and HubSpot in one click, so it slots into existing workflows.
Early signal has been good. A few teams replaced their Apollo subscription with it, and one cut cost-per-meeting in half.
Curious what other founders here think about no-subscription pricing for a data product. Reckless, or the right wedge against the incumbents? Launch link in the comments, feedback very welcome.
Made the same call on the opposite end of the market, so here's a data point. I built LeadGrid (leadgrid.eu) — local-business lists from Google Maps, the exact segment you're deliberately leaving out — and priced it pay-per-list, no subscription, preview before you buy. What I've seen: killing the subscription doesn't cost you the recurring revenue people fear, because those buyers were already churning off annual seats they barely touched. What changes is who shows up — pay-per-use pulls in people with a real job to do that week rather than someone hoarding a login "just in case." The tradeoff is lumpier revenue and no lazy renewals, so you live or die on giving them a reason to come back. The free browsing before a credit is spent is quietly doing a lot of that work; it's what makes pay-per-use feel fair instead of nickel-and-dime. Narrow data plus pay-for-what-you-see has been the right wedge against Apollo for me. Congrats on the launch.
Agreed too that the recurring-revenue fear is mostly about revenue that was never really recurring. Renewal by inertia on seats people had already mentally churned from. You're not losing loyal subscribers, you're losing the calendar.
On "a reason to come back," since that's the whole game: I'm trying to make it workflow rather than a lock. Purchase history so you never buy the same row twice, saved filters, suppression lists. Leave and you lose your own history, which is a cost people feel without me charging a floor for it. Curious whether your pull-back has been the data quality itself or the accumulated workflow.
We're running the identical playbook on deliberately non-overlapping segments, which makes you about the most useful person I could trade notes with, no competitive downside either way. Would genuinely like to stay in touch as both of these play out. And LeadGrid working on local business is a good signal the wedge isn't specific to my niche.
Honest answer: neither yet, which is its own data point.
At $9 a list nobody is building a workflow around LeadGrid. The repeat driver is the job — someone finishes Munich plumbers, wins two clients off it, comes back three weeks later for Stuttgart. The account is incidental to that. Purchase history and suppression lists are the thing I'd expect to matter far more at your ACV, where a buyer spends enough per month that losing their own history is a real cost rather than a mild annoyance.
The one piece of it that has bitten me is dedupe across purchases. Buy two adjacent cities and you get overlap you paid for twice, and the customer files that as "data quality" even though it's a memory problem. Cheap to fix, expensive to ignore. If purchase history already covers that, you've quietly closed the loudest failure mode before anyone hits it.
Happy to stay in touch. Useful to have someone running the same pricing bet on a segment that doesn't touch mine.
The dedupe point is the one I'm taking away, because you just reframed what that feature is for. I'd been thinking of purchase history as a switching cost, a reason to stay. You're describing it as something more urgent: it prevents the complaint people misfile as "bad data" when it's really me forgetting what they already bought. Paying twice for the same row two cities over reads as a quality failure to the customer even though it's a memory problem, exactly as you said. That moves it from a retention nicety to a day-one requirement, and it's the first piece I'm building for that reason.
The ACV difference is the useful caveat though. At $9 the job drives everything and the account is incidental, so I can't just assume your repeat pattern maps onto mine. The honest version is I don't yet know whether my repeat comes from the job the way yours does, or from accumulated workflow the way it might at higher spend. Probably the job first, workflow as a multiplier once the data's proven itself. Data quality is the floor, everything else only matters on top of it.
Glad to stay in touch. Rare to compare notes with someone running the identical bet where there's zero reason to hold anything back.
@joeback That's a really important distinction — "fit data" and "verified buying intent" absolutely have different price ceilings, and conflating them is exactly how you'd end up with a buyer feeling misled even if the data itself was accurate. Smart that someone caught that early. And the wedge-vs-size framing makes sense too — leading with "225k contacts" invites a numbers game you can't win against ZoomInfo, but "stop paying for data you can't use" reframes it as a problem only you're solving. Sounds like day four turned out to be the most valuable day of the whole launch.
The part I'd underline is that the wedge doesn't just position better, it filters better. "Stop paying for data you can't use" pulls in people who feel the waste, which is exactly my buyer. "225k contacts" pulls in people shopping databases on size, who will always leave for whoever's bigger. So switching the headline isn't only about winning the framing against ZoomInfo, it's about attracting the customer who's a fit and quietly repelling the one who isn't. Same self-selection logic as the pricing, which is probably why it clicked the moment someone said it.
And to be fair, I didn't catch the fit-versus-intent thing, a commenter did. That's the whole argument for launching in public instead of polishing in private, the thread found the crack in my positioning faster than I would have.
The self-selection framing is the part I hadn't fully connected. A headline that repels the wrong buyer is doing work before anyone ever reaches pricing — you're not just losing badly-fit customers later, you're not paying to acquire them in the first place. Size-shoppers churn to whoever's bigger next quarter, and you'd have spent the same acquisition cost either way.
The second half is the one I keep thinking about, though. You didn't find the crack, the thread did — and that only works because the positioning was out in the open early enough for someone to push on it. Polished in private, the same flaw survives to launch day and reads as a conversion problem instead of a positioning one.
Which makes me curious how you decide what's worth exposing. Pricing and positioning clearly benefit from the pressure. Is there anything you've deliberately kept back until it was settled, or is the working assumption that everything gets better by being argued with in public?
There's a clear line for me, and it isn't "everything's better in public."
What I expose is the reasoning: pricing, positioning, the bets. Two reasons. Outsiders have all been buyers, so their judgment on those is real rather than guesswork. And being wrong about them in private is the expensive case, the flaw survives to launch and I misread it as a conversion problem instead of a positioning one, which is your point exactly.
What I keep back is three things. The numbers, revenue and how concentrated it is, because that's competitive intel and it resurfaces awkwardly in a raise. The anti-abuse mechanics, because explaining how I stop scraping mostly just helps people scrape. And the sourcing method, because the contact list is copyable and how I build it is the part that isn't. That's the actual moat, so it's the last thing I'd argue about in the open.
The rule underneath it: expose the why, protect the how. Reasoning gets better when someone disagrees with it. Assets and defenses only get more visible to the people who benefit from seeing them. So the test I'm using is basically, does this improve from being argued with, or does it only lose value from being seen. Positioning improves. Sourcing just leaks.
"Does this improve from being argued with, or does it only lose value from being seen" is the cleanest version of that test I've come across. Most of the advice in this space is a volume dial — be more open, be more careful — and this is an actual sorting rule you can apply to a specific thing.
The sourcing example is what makes it concrete. The list is copyable, so the list was never the moat; how you build it is. Explaining that in public would be arguing about the one thing where being disagreed with buys you nothing.
The revenue point is the one I'd have gotten wrong. I'd have filed numbers under harmless-but-boring rather than something that resurfaces awkwardly later. Useful to have that pointed out before I'm in the position to make the mistake. Thanks for laying all of this out — genuinely one of the more useful threads I've been in here.
The pricing philosophy here is rock solid - you're essentially saying "pay for access to the data only when you've proven it has business value for you." That self-selection is powerful because it means your early customers are pre-validated: they didn't balk at the price, so they're serious about using it.
One observation: the freemium approach also gives you something more valuable than revenue in year one - real usage data and product-market fit signals. If users are building their workflows around your database, sticking through month 3, and asking for features they can't live without, your pricing floor just went up naturally.
Most founders underprice because they're uncertain about value delivery. But if you're confident enough to charge from day one (even at a freemium tier), you're already ahead of 90% of founders who will spend a year fighting to raise prices on customers who adopted at $0.
One correction on the framing, because I think it changes the read: this isn't freemium. There's no free tier anyone can actually work in. The preview shows you the match exists, it doesn't hand you the contact, so nobody can camp on free and get the job done. That matters, because freemium's classic failure mode is a big free base you spend two years trying to convert. My version doesn't have that problem. It has a different one, which is that the moment of truth arrives on every single purchase, forever.
You're right about the PMF signal, and I'd sharpen it: the second purchase is the signal. Nothing auto-renews, nobody gets billed by default, so someone coming back to spend again is an unforced act every time. That's a cleaner read on value than a renewal rate, because renewal is partly just inertia and a calendar.
One thing I'd add to your last point. Charging from day one does dodge the raise-prices-on-free-users problem, agreed. But per-unit pricing has its own trap: the number is visible on every transaction. A subscription can absorb an increase behind a new tier or more features. Moving $0.08 to $0.10 is arithmetic my customers do in their heads, instantly. So I've traded the painful repricing conversation at year two for a number I can basically never move. Not obviously worse, but it isn't free either.
not reckless, but the thing to watch flips. usage pricing kills the churn reason you named, and it hands your revenue the same variance your customers' usage has. a few heavy accounts carry you, a long tail browses free and never spends a credit. so the number that tells you it worked isn't arpu, it's what % of signups ever spend once and how concentrated the spend is. if it concentrates hard you've quietly rebuilt the 'one big customer' risk on your own side, and the fix is a small team floor, not annual contracts again. curious what the spend spread looks like so far on the teams that dropped apollo?
The metric reframe is right, and ARPU is actively misleading in this model. Average one heavy account and forty browsers and you get a number that describes nobody. The two I watch instead are what share of signups ever spend a first credit, and what share of revenue sits in the top few accounts. Activation and concentration, not the average.
Where I'd push back is the floor. A team floor is a seat with a smaller number on it. The moment someone owes me money whether they pull data or not, they're back to asking "am I using this enough to justify this," which is the exact question the model exists to remove. I'd rather fix concentration from the other end: widen the base so no single account matters that much, rather than tax the tail to smooth the curve.
Which makes the long tail an activation problem, not a pricing one. If someone browses and never spends, it's usually that the data didn't match what they came for, or the first purchase felt riskier than it should. Both are fixable without charging anyone a floor, and fixing them does more for the variance than a minimum ever would.
On the spread: fair caveat though, the sample is small enough that real concentration and plain small-n noise look identical right now. Worth asking me again in a few months, when the answer actually means something.
That buyer database angle is smart — seems like you're betting that narrower intent = higher willingness to pay compared to a general B2B contact database. What made you confident enough to commit fully to SaaS-only?
Thanks I talked with many peers in the space who felt the need was there to build something new and contrarian than the contact databases that already exist. So for me it was an easy decision as the pain of these interchangeable vendors don't provide enough value.
I think no-subscription pricing is a smart wedge here, especially for teams that only need data in bursts. It removes the “am I using this enough to justify the seat?” problem.
The tradeoff is that your best customers may eventually want predictable volume pricing. I’d be curious whether heavy users start asking for prepaid bundles or monthly credits once they trust the data quality.
The burst point is the one I'd underline. Bursty usage is exactly the profile seat pricing punishes hardest, because you pay flat for twelve months to use it properly in three. That's most of the teams I talk to.
And yes, a couple of heavier users have already hinted at wanting bundles. The design constraint I'd hold is that any bundle has to keep the core promise, so non-expiring credits or an automatic rate break rather than a prepay-or-lose-it pack. The moment unused balance expires, I've rebuilt the thing I was selling against.
The SaaS-only filter is a smart positioning move — the real test is whether buyers in the database explicitly self-identified as acquisition targets or whether you inferred it from signals like tech stack or revenue range.
Databases where the buyer intent is verified command premium pricing because that signal is genuinely scarce. Databases built by filtering general company data can be reconstructed by any competitor — the moat is the intent signal, not the contact list itself.
The pricing thesis sounds interesting: what is the assumption underneath it? If it is that SaaS buyers close faster at higher deal values so sellers rationally pay more per verified lead, that is a hypothesis the market will confirm quickly. The first week of Product Hunt traction will tell you whether the positioning is pulling buyers in or whether you need to educate them on why SaaS-specific targeting matters.
Genuinely curious what the sourcing model is for the database entries — that detail determines almost everything about whether this scales.
Worth being precise here, because I think you're describing a different product than the one I built. Backchannels is a fit database, not an intent database. It tells you someone is a software decision-maker who matches your ICP, not that they're in-market this quarter. I'd rather say that plainly than let "SaaS-only" get read as verified buying intent, because it isn't.
You're right that the intent signal is the scarcer asset, and it's the layer I want on top rather than the thing I'm claiming today. Someone else on this thread made a good case for funding recency as the first signal to add, and I think that's the right direction.
On sourcing: [describe your actual model here, at whatever level of detail you're comfortable with]. Happy to go deeper on it.
That's a useful correction — fit vs. intent is exactly the right frame, and the distinction matters commercially. "This person matches your profile" and "this person is actively looking this quarter" are different promises with different price ceilings and different sales motions.
The honest positioning is probably stronger with the right buyer: someone who already has an intent signal layer and needs clean, accurate fit data on top will appreciate that you're not overselling it. Overselling the intent angle to someone who gets burned once tends to end the relationship.
The funding-recency direction makes sense as the natural expansion — it's one of the few external signals that actually correlates with buying mode without requiring inference. Good luck with the PH launch.
The layering point is the practical consequence. Being clear this is fit data means it sits underneath an intent layer rather than pretending to be one, which changes who's a partner versus a competitor.
Your last line surfaces something else too: in a per-credit model, overselling gets punished faster than it would on a subscription. Someone who gets burned doesn't wait for a renewal date to leave, they just stop buying, and I see it that week. The model makes overclaiming expensive in a way an annual contract would cushion. That's a decent argument for the pricing on its own.
Hi! Congratulations on launching Backchannels on Product Hunt.
I read your post carefully, and I really liked the way you explained the reasoning behind the product instead of just talking about features.
The decision to focus exclusively on software buyers makes a lot of sense to me. In many SaaS products, a smaller, high-quality dataset is much more valuable than a massive database filled with irrelevant information. I also think the pay-per-contact model is a smart way to reduce friction for customers who don't want another expensive annual subscription.
I'm a software engineer focused on building SaaS products, backend systems, APIs, AI-powered features, and workflow automation. I enjoy working with founders, solving technical challenges, and helping turn product ideas into scalable software.
Your product is the kind of SaaS I'd genuinely enjoy building. If you're open to connecting, I'd love to learn more about your vision and see whether there's an opportunity for us to collaborate. Even if you're not looking for another engineer right now, I'd still enjoy exchanging ideas.
Congratulations again on the launch, and I wish you and Backchannels great success.
Thanks, and I appreciate you engaging with the reasoning rather than the feature list.
I'm building solo and staying lean for now, so I'm not bringing on engineers at this stage, but I'm always up for trading ideas with people building in the same space. Best of luck with your work.
The pay system sounds incredible, one thing to watch out for: pay per use is a good idea, but if people try to cheap you out and find ways to maximize their use while spending as little as possible this could hurt your revenue, just something to look into. I wish you all the best though
Fair flag, though I'd argue that's the model working. If someone browses carefully and buys 40 contacts instead of 4,000, they got what they needed and I got paid for data that was worth paying for. Small baskets aren't the threat. People not coming back is the threat, and that's a data quality problem, not a pricing one.
The real version of your concern is abuse of the free browse layer rather than frugal buying, and that one I'm watching closely.
the pay system is smart. users won't churn. I wish you all the best. Keep growing
Thanks. I'd temper it slightly though: churn doesn't disappear, it just gets quieter. Without a renewal date nobody formally leaves, they just stop topping up, so I have to go looking for it instead of getting a cancellation email. Different problem, not a solved one.
both bets are strong and they reinforce each other: niching the data is what makes pay-per-contact credible. "225k software decision-makers, browse free, pay $0.08 only for what you take" is a genuinely different promise from the annual-contract incumbents, and it removes the biggest objection (paying for data you never use). one risk to watch: pay-per-use can anchor people to "cheap" and cap your revenue if power users learn to browse carefully and buy little. worth testing a credit pack or a light subscription for heavy users later, not to kill the model but to capture the people who WANT to spend more. and lead every bit of marketing with the wedge, not the size: "stop paying for 80% data you cant use" lands harder than "225k contacts", because the pain youre removing is the filtering + the wasted subscription, and thats the thing your buyers actually feel. congrats on the launch.
The marketing point is the most useful thing anyone's said to me today. "Stop paying for 80% data you can't use" absolutely lands harder than "225k contacts," because the size number invites a comparison I lose against ZoomInfo, while the wedge names a pain they feel every week. Reworking the headline around that.
On the revenue cap, agreed it's the risk, but I'd fix it without a wall. A prepaid pack rebuilds the allocation waste I just attacked, only smaller, so it'd probably be non-expiring credits or an automatic rate break as volume climbs. Capture the people who want to spend more without making anyone pay for rows they never pull.
"Narrow data beats big data" really stood out. It feels like more founders are realizing that being the best for a specific use case can be much more valuable than trying to serve everyone. Excited to see how this pricing experiment plays out.
The hard part of narrow is holding the line. The second you get traction, people ask for adjacent segments, and every "can you also add agencies" is a small step back toward the general database I was trying not to build. Saying no to that is the whole strategy, not a side effect of it.
I really like the pricing approach. Charging only for the contacts users actually need feels much more customer-friendly than another expensive annual subscription. The niche focus is also a smart decision—quality is often more valuable than a massive database. I'd be interested to see how this model performs over the next few months. Good luck with the launch!
Thanks. The next few months are the real test, and it's a different test without a renewal date. Nobody gets auto-billed into staying, so people either come back because the data worked or they quietly don't. That's a harsher scoreboard than renewal rate but a more honest one. Appreciate the good wishes.
not reckless, it's the right wedge. the thing apollo/zoominfo can't easily copy is killing the "paying for a seat we barely use" objection, that's their most hated trait and half their churn. where i'd watch it: usage pricing wins the trial and the light users, but your heaviest users are the ones who'd happily pay a subscription, and you've now trained them to count credits. i'd keep pay-per-contact as the front door and add an optional credit-pack tier once a team hits real volume, so you recapture predictable revenue from the whales without rebuilding the annual wall you just tore down. and "browse free, pay to reveal" is the right spot for the paywall, just watch for scraping on the free layer.
Agreed on the wedge, and the whale question is the one genuinely open thing in the model.
Where I'd be careful with credit packs: if the pack is "prepay for 10,000 credits," I've rebuilt the allocation waste I just attacked, only smaller. Someone buys 10k, pulls 3k, and the unused balance is the same dead money as an unused seat. So a volume tier has to keep the promise intact, which probably means credits that don't expire, or an automatic rate break that kicks in as you pull more rather than something you commit to up front. Predictable revenue from the heavy users, no wall, nobody paying for rows they never touched.
Your point about training them to count credits is the sharper one though. Metering has a cognitive cost, heavy users start rationing, and rationing suppresses exactly the usage I want. That's the better argument for a volume tier: less about recapturing revenue, more about getting the counting out of their head.
On scraping, fair flag. What makes it survivable is that the free layer proves a match exists, it isn't the asset. Verified contact detail sits behind the paywall, so scraping the preview mostly gets you names you could have pulled off LinkedIn anyway. Still an operational tax, and I'd rather not spell out the defenses in public, but it's on the radar.
Congratulations on the launch! Wish you the best!
Thank you so much, feel free to give it a try sometime - would love your feedback
Congratulations on the launch! I really like that you're sharing the thinking behind your pricing decisions. Wishing you a successful Product Hunt launch.
Thank you I appreciate the support and kind words. Hopefully you can try it out sometime as well!
Congrats on the launch! The pay-per-contact bet is interesting to me because I run a similar credit-based model for an AI ad tool, and the "quiet churn" thing you mentioned in the comments is so real. No renewal date means no clear signal when someone's done, they just stop buying credits. I've been thinking about the same problem, curious if you find a good way to catch that early before it just looks like normal usage dips.
Good to find someone in the same boat, credit models make this problem so much sharper than seat-based ones do. Here's where I've landed so far, though I'm still figuring it out too.
What's helped most is measuring dips against each account's own baseline instead of an absolute number. A team that buys every week going three weeks silent is a real signal; the same gap from a monthly buyer is nothing. So I track days-since-last-purchase relative to that account's median interval and flag when someone breaks their own rhythm, rather than watching a global average.
The other piece is leading indicators before the buying stops. Logins and searches usually decay before purchases do, so someone still showing up and running filters but not spending is a different problem (friction, or they stopped finding value) than someone who's gone fully dark. Catching that first group is where the save actually happens, because by the time purchases stop you're often too late.
Still doing a lot of it by hand while I'm small enough to. Would genuinely like to compare notes as you go, sounds like we're solving the identical thing from two directions.
Congrats on the launch, the SaaS-only niche plus pay-per-contact pricing is a smart combo. One thing worth layering on top of a "who" database like this: filtering by when a company got new budget, not just whether they're a software buyer. SEC Form D filings (how private companies disclose raising capital) are public and go live within 15 days of a raise, so cross-referencing "just raised funding" against a niche buyer list cuts a lot of wasted credits, you're not paying for a contact whose company has zero budget signal right now. Even a simple "raised in the last 90 days" filter would probably raise your reply rates a good bit.
This is a great call, and it's the axis a pure "who" database is missing. Being a software buyer tells you someone could buy, timing tells you they might right now, and funding is one of the cleanest budget signals there is. Form D is a smart source for it, public and fast.
A "raised in the last 90 days" filter is exactly the kind of intent layer I want sitting on top of the static list, so this is squarely the direction. The thing I'd want to get right: funding is one timing signal, not the only one. New exec hires in the buying function and fast headcount growth often move budget as much as a raise does, and Form D misses the bootstrapped and revenue-funded teams entirely. So I'd build it as one signal in a stack rather than the whole intent story. But you've named the highest-leverage one to start with. Appreciate the specific pointer, that's a useful one.
I like that you questioned the industry's default instead of copying it. Removing subscriptions lowers the risk for startups, and that's exactly the kind of thinking that gets people to try a new product. Congrats on the launch, looking forward to seeing how Backchannels grows. Also open to working as an Executive assistant and social media manager , if u ever need one
Thanks, appreciate that. Questioning the default was the whole starting point, so it's good to hear it reads as a reason to try the product rather than a risk.
On the EA and social side, I'm keeping things lean and running the social myself for now, since it's founder-brand-led and tough to hand off, but I appreciate you putting it out there. I'll keep you in mind if that changes as we grow. Best of luck with the search.
Congrats on the PH launch — the niche-first bet is the part that feels bravest here.
Most contact tools race to "more rows," so shipping SaaS-only (and accepting a smaller TAM) is a real positioning choice. On the no-subscription side: curious what early buyers say when they compare total spend after ~30 days vs the Apollo seat they replaced. Does pay-per-contact feel cheaper in practice, or just clearer?
Thanks. The smaller TAM was the deliberate part, I'd rather own the software niche completely than be one more general database competing on row count.
On spend, the honest answer is usually both, for a specific reason. The thing nobody says about seat pricing is how much of the allocation goes unused. People buy 10,000 credits, pull 800, and pay again the next year for the 9,000+ they never touched. Pay-per-contact just stops billing them for the waste, so "cheaper" for most buyers isn't a discount, it's not paying for what they didn't use. Clearer comes on top, since you always know exactly what a given list cost, no annual true-up.
Where I'll be straight: a genuine high-volume user who burns their whole seat every month can come out cheaper on a flat plan. Those aren't really the buyers this is built for, and I'm fine with that. Too early for clean 30-day cohort numbers, but the teams who've switched so far skew lighter and mid-volume, which is exactly where the savings are real.
Interesting pricing strategy. Removing the subscription definitely lowers the barrier to trying the product. I also like the niche-first approach—focusing only on software buyers seems much more valuable than offering a huge database filled with irrelevant contacts. Curious to see how customer retention compares over the long term.
Thanks, appreciate that. The niche-first call was the one I was most nervous about, since every instinct in this category says a bigger database wins, so it's good to hear it reads as more valuable rather than thinner.
Retention is the metric I'm watching hardest too, and it looks different without a subscription. There's no renewal date, so nobody formally churns, they just stop topping up. That makes the signal quieter and slower to read, so I'm tracking top-up cadence instead of renewals and reaching out to anyone who goes quiet while I'm still small enough to ask. Too early to call it, but that's the number that'll tell me whether the model actually holds up long term.
Good luck with the launch today! Curious about the pricing bet you mentioned — did you go higher or lower than what felt "safe," and what made you decide to take that risk?
Thank you I didn't go higher than safe for me the price per customer isn't the biggest driver, I want users to get value.
That's a solid philosophy — optimizing for perceived value over squeezing the highest number per customer tends to pay off more in retention and word-of-mouth anyway. How's the launch going so far today?
Steadier than I expected for a midweek launch, and the comments have been more useful than the traffic honestly. A few of them have already changed how I'm going to describe the product.
Glad to hear the comments turned out to be more valuable than the raw traffic — that's honestly the underrated part of launching in public. What kind of feedback ended up reshaping how you describe the product?
Still gathering more feedback as we speak so the more the better!
Sounds like a good sign that the feedback loop is still active this many days in — a lot of launches go quiet fast, so ongoing engagement is a good signal in itself.
Thanks. The later comments have been better than the launch-day ones. Day one brings volume and congratulations, day four brings the people who actually read the thing and want to argue with a specific decision. Two or three of them have already changed how I describe the product.
"Day one brings volume, day four brings the people who actually read the thing and want to argue with a specific decision" is a great way to put it — that's basically the difference between validation and just noise. Curious which specific decision got challenged the most — was it the pricing itself, or more the positioning/description around it?
Positioning, not pricing, and it surprised me. Almost nobody argued the $0.08 or the pay-per-contact model. What got challenged hardest was a word: I'd let "SaaS-only" get read as verified buying intent, and someone rightly pushed that it's fit data, not intent. That correction changed how I'm going to describe the whole thing, because those are two different promises with different price ceilings, and blurring them is how you burn a buyer who expected in-market leads.
The second most-argued thing was marketing framing, that I should lead with the wedge ("stop paying for data you can't use") instead of the size ("225k contacts"), because the pain is the thing buyers feel and the number just invites a comparison I lose to ZoomInfo.
The pay-per-contact bet has a second-order effect worth planning for: it turns every single credit into a small trust test. Someone spends 8 cents, the contact is stale, and you've lost them in a way a subscription competitor wouldn't have. An annual subscriber already sank the money and will tolerate a couple of bad rows. Yours hasn't and won't.
Sounds like a risk, but it's probably your sharpest line. You can say out loud that you only get paid when someone finds a contact worth paying for, and none of the annual-contract crowd can say that without lying. That's a better differentiator than the SaaS-only dataset, honestly, because a data niche is copyable and a pricing posture isn't, not without them torching their own revenue model.
The thing I'd watch is quiet churn. With no renewal date nobody formally leaves, they just stop topping up, and you won't spot it in the numbers until it's a quarter old. Worth asking the ones who go quiet what happened while you're still small enough to ask.
You're right, and I'd push it further: raising the stakes on every row is the point. A subscriber pays up front and forgives a few bad contacts because the money's already spent. Mine hasn't paid yet, so every credit has to earn it. Uncomfortable, and also the thing that keeps us honest. Revenue only moves when the data's genuinely worth paying for, so quality stops being a roadmap line and becomes the business.
The preview does more work here than people expect. You see the match before you spend the credit, so you're never buying blind.
The pricing-as-moat framing is sharper than how I'd been putting it. A SaaS-only dataset is copyable. "We only get paid when you find someone worth paying for" isn't, not without a competitor blowing up their own ARR to match it. Taking that line.
Quiet churn is the one that actually worries me, for the reason you gave: no renewal date means no moment where anyone tells you they're done, they just go quiet. So I'm treating days-since-last-purchase as the renewal signal I don't otherwise get, and reaching out to anyone who was active and went dark, by hand, while I'm still small enough to. Already teaching me more than the dashboards. Appreciate you thinking past the pitch.
Fair on the preview, though I'd split what it does and doesn't cover. It de-risks relevance, you can see the match is the right sort of person before you spend. It can't de-risk freshness, whether they're still in that role and whether the email still lands. That's the one that actually burns people, and it's invisible at preview time.
Which makes per-credit interesting again, because staleness becomes a revenue problem instead of a support ticket. If you can put a recency signal next to each contact, even just when it was last verified, you're heading off the exact objection that stops someone spending a second credit.
Good luck with today, hope it goes well. Mine's on Sunday, so I'll be watching how the midweek crowd treats you.
You've drawn the line exactly right. Preview de-risks relevance and does nothing for freshness, and freshness is the one that actually burns people, because it's invisible at the moment you're deciding to spend. Right person, wrong role, dead inbox, and preview can't see any of it.
A recency signal is the fix, and it's exactly where per-credit pushes me. A last-verified date next to every contact turns freshness from a hidden gamble into something you can see before you spend, which is the whole point of charging per row instead of per seat. That's high on the build list for this exact reason. I'm also leaning toward crediting back anything that bounces, so a stale row costs nothing but the click. Between the two, freshness stops being the thing that kills the second credit.
Good luck Sunday, I'll be watching, and happy to send whatever support I can when you go live. The midweek crowd's been fair to me so far, hoping yours shows up the same way.
Crediting back the bounces is the stronger half of that pair, I think. A last-verified date is a claim about your data. A refund on a dead row is a promise you're standing behind. One asks them to trust the number, the other means they don't have to.
It also makes the pricing line airtight. You stop saying we only charge for data worth paying for and start demonstrating it every time something bounces, which is a much harder thing for a competitor to copy than a dataset.
Thanks, genuinely. Same to you for the rest of the week, I'll keep an eye on how yours lands.
You've convinced me the refund is the load-bearing half. A date asks them to trust my number, a credit back means they don't have to. I'll do both, since the date prevents the bad purchase and the refund covers what slips through, but you're right about which one is the actual promise.
Good luck Sunday, I'll be watching for it.
The pay-per-contact model is the part that stood out to me.
Charging only when someone finds data they actually want changes the buying conversation quite a bit. If that model holds up over time, it could become as much of a differentiator as the SaaS-only dataset itself.
Thanks the the goal is to have an outcome pricing model in the future as well, instead of just the typical subscription model
That makes sense.
The interesting question will probably be whether customers naturally value the outcome enough to pay differently, or whether they still anchor on access and volume.
Would be curious to see what the market teaches you there.
Appreciate the context.
The move from paying for access to paying for outcomes is an interesting pricing shift.
Would be good to understand how you're thinking about that transition and what you're learning from customers.
What's the best email to reach you on?
The market's starting to answer this already. Most buyers still anchor on volume, because Apollo and ZoomInfo trained them to ask "how many contacts do I get." The preview quietly re-teaches it: filter, see 60 exact-fit contacts next to the 6,000 you'd have bought blind, and the anchor moves from how many to how right on its own.
I'd stop short of calling it outcome pricing though. I don't control your copy or your timing, so charging per meeting would be taking credit for work I didn't do. Per contact you choose to keep is as close to outcomes as a data vendor can honestly get. Still early, and customers will teach me the rest. Happy to get into it here.
You can reach out directly [email protected]
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
Received and yes we'll touch base thank you!
Not reckless - this is the confidence play that actually works. Most SaaS teams keep subscriptions because recurring revenue feels safer, but you just proved that solving the real pain (seat waste) is more valuable than subscription predictability. The "free browse before paying" removes the commitment anxiety AND lets customers prove value to themselves. Apollo lost teams because they couldn't justify the monthly seat they barely used - you removed that objection entirely. Early switchers from incumbents is the signal that matters most here, more than any pricing theory.
Agreed on the switcher signal, that's the number I trust most too, and I'd add the reason it's stronger than theory: switching costs money and effort, so someone leaving a tool they already pay for and have wired into their workflow is voting with real friction behind them. A new signup can be curiosity. A switcher moved their outbound off a system that already worked well enough to keep paying for, which is a much harder thing to fake.
The one caveat I'd put on it: they've proven the wedge pulls people off Apollo, not yet that they stay. Switching in on a lower-risk pitch is the easy half. The model doesn't have a renewal date holding anyone, so the real proof is the second and third purchase months from now, not the switch itself. Early, but that's the number I'm actually waiting on.
Not reckless — for a data product it's the right wedge, and here's the specific reason: usage-based works when the value is inspectable and discrete. "Browse every match free, spend a credit only on what you want" removes the exact thing people hate about Apollo — paying for a seat and a data pool they barely touch. You've turned the buyer's biggest churn reason into your pitch.
The real risk isn't churn, it's the two things subscriptions quietly buy you: revenue predictability and commitment. A pure pay-per-contact user has zero switching cost the day a competitor undercuts $0.08.
If I were hedging that without reintroducing the thing people hate, I'd test slow-expiring credit packs (bulk buy, small discount → soft commitment) or a light "seat + credits" tier for teams who pull data weekly. Keep browsing free forever; just give power users a reason to pre-commit. Congrats on the launch.
The switching cost point is the sharpest thing in the thread, and I'd solve it somewhere other than pre-commitment. A credit pack is a lock, not a reason to stay, and locks are precisely what people resent about the incumbents.
The switching cost I'd rather build is workflow and history: knowing which contacts you've already pulled so you never buy the same row twice, saved ICP filters, suppression lists, a CRM sync that's already mapped. Leave and you lose your own purchase history, which is a cost you feel without me imposing it. Earned rather than charged.
On someone undercutting $0.08, they can, and in data cheap and wrong is the most expensive thing you can buy. A bad row costs a send, a hit to domain reputation, and a rep's time, none of which shows up in the unit price. I'd rather compete on accuracy than defend a number anyone can copy in an afternoon. For what it's worth, slow-expiring is the version of your idea I could live with. It's expiry that rebuilds the waste I was attacking.
I think the pay-per approach is great, particular for early adopters and small startups.
Conversely, I think you should consider using that as an initial hook and transitioning people into a more traditional subscription once they research a certain volume.
Usage is more sporadic / volatile when usage is low, so it makes sense then. You can even charge at a higher effective unit cost at that point, compared to larger subscription plans, because it's the absolute and not marginal cost companies care about when they're small.
Another advantage to your model is the confusion / obfuscation of pricing, particularly around subscription+credits hybrids.
Related problem in this area: search sucks across all of the main providers. It's like some weird 1980s library database of keywords and ontologies. For example, let's say I want to find PropTech companies using AI - it's next to impossible to get a comprehensive and accurate list with tools like Apollo.
How was the launch?
The absolute versus marginal framing is right, and it's why any volume break should trigger automatically rather than move someone onto a different plan. A small team doesn't care that their unit cost is higher than an enterprise rate, they care that the invoice is small. Discount the unit as volume climbs, no commitment, no migration.
Your point on hybrid pricing confusion is exactly why I'm wary of the tier a few people have suggested. The moment you have seats plus credits plus rollover plus overage, you've rebuilt the pricing page nobody can parse, and clarity was half of what I was selling.
The search comment is the most useful thing anyone's raised though. You're right that it's a 1980s keyword and ontology problem. "PropTech companies using AI" fails because it's an intersection of vertical and technology, and most of these tools model one axis properly while inheriting a static taxonomy built for the entire economy. That's the strongest argument for narrowing the dataset I've heard, because covering only software means I can model that space properly instead of maintaining a taxonomy for every industry on earth. Intersection queries are exactly where I want to be good.
The pricing move is brilliant because it's not really about the business model - it's about customer psychology. Paying per-contact forces founders to demonstrate real value fast. Your customer can browse free and decide with zero risk. That's confidence in the product.
Most founders underprice because they're uncertain if their product actually works. They hide behind subscriptions to smooth out the fear. You're doing the opposite: prove it works, then charge. This also aligns incentives perfectly - you make money when you solve a real problem, not when you're just sitting on someone's license.
Generous read, but the honest version is less noble. It looks like confidence in hindsight. At the time it was partly that nobody signs an annual contract with a database they've never heard of. No brand, no track record, so asking for a year of budget up front was never really available to me. The pricing was as much a constraint as a conviction.
The alignment point is real though, and it cuts both ways. I only get paid when someone finds a contact worth paying for, which is great for trust and unforgiving on execution. A subscription vendor having a bad quarter still gets paid. I find out immediately, on every single purchase. The part people call brave I mostly experience as pressure.
Consumption pricing is how Azure ate the enterprise, so the wedge is proven; buyers trust a meter more than a contract they might waste. The move that made it work in the Microsoft channel: once an account shows steady monthly usage, offer committed-spend tiers at a discount, and you get recurring revenue back without reintroducing the churn reason you just killed. And keep leading with the cost-per-meeting-cut-in-half stat, that number sells this better than the $0.08.
The Azure parallel is a good one, with one difference I'd watch: cloud consumption is continuous and fairly predictable, so committing to a spend tier is low risk for the buyer. Data buying is lumpy and project-shaped, so a commitment carries the same "will I actually use this" anxiety that kills seat renewals. Same mechanic, different risk profile for the customer. I'd want any tier to be a rate break that triggers on volume rather than something you promise up front.
On the stat, I'm holding off for now. That number came from one customer, and until it holds across more accounts it's an anecdote rather than a headline. When I've got a handful saying the same thing, it leads.
Hello, I’m a software engineer interested in building AI-powered SaaS products. I’m here to learn from other founders and developers, exchange ideas, and connect with people working on interesting projects. Nice to meet you.
Hi thanks for introducing yourself and nice to meet you as well
Hello,
How are you?
Now I am looking for a business partner (US) who can help me.
This is a part-time job, and you only work 2~3 hours per week.
Monthly payment: 40% of income.
This is a fully remote opportunity.
Thanks.
Here's the link to Product Hunt: https://www.producthunt.com/products/backchannels?utm_source=other&utm_medium=social
This comment was deleted 13 days ago.