We Put the Paywall Before the Product. It Cost Us 143 Accounts.
For most of this year, a new JuggleHire account could not post a job, view its career page, or click a single feature until it entered a credit card. I did not design it that way on purpose. It happened the way most bad things in a product happen: one reasonable decision at a time, and then nobody measured the result.
I measured it this week. 305 teams signed up in 2026. 143 of them stopped at the plan screen and never came back.
This is what that measurement looked like, why the number was invisible for so long, and what I got wrong about my own funnel.
The funnel, one step at a time
I had been guessing about churn for two years. Guessing is comfortable because it never contradicts you. So instead of guessing, I counted how many teams survived each step, using production data for every team created since January 1 with a verified owner email.
| Step | Teams | Survives |
|---|---|---|
| Signed up | 305 | |
| Verified email | 293 | 96% |
| Passed step 1 (org details) | 263 | 90% |
| Started a plan or trial | 120 | 46% |
| Created a job | 111 | 87% |
| Published a job | 103 | 93% |
| Got at least 1 application | 59 | 57% |
| Got at least 5 applications | 36 | 61% |
Read down that column and the shape is obvious. Every step holds 87% or better, except two. One of them loses more than half of everyone who reaches it.
143 accounts died at "started a plan." That is not a leak. That is the floor of the boat.
Why I could not see it
Two reasons, and both are worth naming because they are common.
The first is that aggregate metrics hide step changes. I had MRR, I had churn, I had a trial-to-paid rate. Not one of those numbers can tell you where people stop. They summarise the survivors. A funnel that loses 54% at step four and a funnel that loses 54% spread evenly across eight steps produce similar top-line numbers and require completely different fixes.
The second is that the wall did not look like a wall in the code. The middleware routes an incomplete account to the plan step whenever there is no active subscription, and blocks every other route until setup is finished. Written out as a sentence, that sounds like ordinary onboarding. What it actually means is that a person who has just verified their email and typed in their company name is now standing in front of a payment form, having watched the product do exactly nothing.
I wrote that middleware. I read it many times. I never once read it as "nobody sees the product before paying," because I already knew what the product did.
The part that removed all doubt
A funnel drop can be explained away. Maybe those 143 people were tire-kickers. Maybe they were never going to buy. That is the comfortable story, and I told myself a version of it for a while.
So I checked what the stuck accounts did next.
Of the 166 verified owners who never completed setup, one created a job. Zero published one. Zero received a single application.
That is not a soft discouragement, where some determined users push through and others drift away. It is an absolute gate. Nobody gets past it. And of the 127 teams who did complete setup, 119 have a subscription row and 12 are grandfathered lifetime accounts, which means essentially nobody enters this product without paying first.
Then the last detail, the one I keep coming back to: 293 of those 305 people verified their email. They went to their inbox, found the message, and clicked the link. That is not the behaviour of someone who wandered in by accident. Those were interested people. 144 of them are now more than thirty days old, which in practice means they are gone for good.
The second leak, and why it is worse than it looks
Look again at the table. 103 teams published a job. Only 59 ever received an application. Forty-three percent of everyone who successfully used the product got nothing back from it.
I found the cause the same week, and it is embarrassing. Every job URL in every tenant's job feed and sitemap was being built from the wrong field. The code passed the team's subdomain into a route parameter that expects a full hostname, so instead of threadedcareers.jugglehire.com, every published job pointed at threadedcareers. That host does not resolve. It never resolved.
This affected all 269 teams with live jobs, in both the feed and the sitemap, and it had been live long enough that I cannot tell you when it started. The files looked fine at a glance because the static entries in them, the ones pointing at the main site, were correct. Only the job URLs were dead, and those are the only ones that matter.
Put the two leaks next to each other and you get a machine that fails at both ends. New users cannot get in without paying. The ones who pay and publish are broadcasting into a void, get no applicants, and reasonably conclude the product does not work.
That is the honest explanation for a lot of churn I had previously filed under "wrong ICP."
What I actually got wrong
Not the pricing. Not the positioning. Not the market.
I got the order wrong. The product asks for money before it has done anything for you, and I had convinced myself this was a reasonable filter for serious buyers. It is not a filter. A filter implies something passes through it. This stopped 143 people who had already told me twice that they were interested, once by signing up and once by verifying their email.
There is a broader lesson in here that I did not enjoy learning. For two years I treated JuggleHire's problem as strategic. Wrong customer, wrong niche, wrong story. I wrote long documents about it. Three separate diagnoses told me to go talk to customers, and each time I responded by shipping more features, because building is the part I am good at and the part that feels like progress.
The actual problem was sitting in a middleware file the entire time, and it took one afternoon of counting rows to find it.
What I am doing about it, in order
Ranked by accounts recovered, not by how hard they are:
- Move the paywall behind the first published job. Let people set up, post a role, and see their career page before anything asks for a card. This is the 143-account fix.
- Fix job visibility. Correct the host in the feed and sitemap, and repair the aggregator submit links. Publishing has to actually produce applicants, or fixing step four just moves the corpse to step six.
- Only then look at trial-to-paid. It currently sits near 11% against a healthy benchmark of 15 to 25%. That number is close to meaningless while the two problems above are live, because the population it measures has been filtered by a broken funnel.
The ordering matters more than any individual item. Optimising trial-to-paid while 143 people a year cannot reach the trial is the kind of work that feels productive and changes nothing.
The method, which is the only part that transfers
If you take one thing from this, do not take the specifics of my funnel. Take the method, because it is embarrassingly cheap.
Count how many accounts survive each step. Attack the single biggest drop. Repeat monthly.
That is the whole thing. It took an afternoon. It replaced two years of theorising about churn with a located, countable problem and a fix I could ship.
A few practical notes from doing it, which cost me more time than the counting did:
- Check your columns are alive before you trust them. Two fields I had been reading for subscription state turned out to be empty for every row in production. Reading them silently labels every paying account as free, which quietly poisons any metric built on top.
- Do not trust row-count estimates. Count properly, even when it is slower.
- Find the join that reflects reality. One table I expected to use had a null tenant ID on 42,523 of its 42,588 rows, so it had to be joined through a different path entirely.
Each of those looked like a small data-hygiene issue. Together they were the reason the funnel had never been measured. Every attempt to look produced numbers that seemed plausible and were wrong, and plausible wrong numbers are worse than no numbers, because you stop looking.
Where this leaves things
I have a pre-product-market-fit product with a paywall in front of the product, publishing jobs to a hostname that does not exist. Written down like that, the last two years make considerably more sense than the strategic explanations I preferred.
I will report back with what the funnel looks like after the paywall moves. If the 46% step recovers to something normal, the strategy conversation I have been having with myself since 2024 was mostly a way of avoiding an afternoon of counting.
That would be a genuinely annoying outcome. It would also be the most useful thing I learn this year.