We moved the paywall off the draft and onto the send
Old flow: you sign up, you pick a job, you hit a wall. Pay to see anything.
New flow, shipped this week: you sign up, you pick a job, and you watch your application get written. Resume rewritten against that specific posting. Cover letter in your voice. Every field on the company's form mapped and filled.
Then the wall. Sending it is what a plan buys.
Why I could afford to give away the expensive-sounding half
I assumed the preparation was the expensive part. It sounds expensive. It is the part with all the AI in it.
It is not. Measured on our own rig:
- one full preparation: about 1,200 billed tokens
- the floor a free account already holds: 27,000
So the thing that felt like giving away the product costs about four percent of a grant we were already handing out at signup. Meanwhile the genuinely expensive part, a real browser session driving a real hiring system for twenty minutes, sits entirely behind the wall and always did.
I had the cost model in my head backwards for months, and it shaped the funnel.
The failure mode I nearly shipped
Opening the preparation and closing the send has to happen in the same commit. Otherwise you have simply made the product free.
I nearly did not. The wall had a bypass: a second route reached the same prepared document from a different direction. I found it by grepping for readers and writers of the link between an application and its document, and finding four readers and zero writers. Nothing had ever written the link. The check that was supposed to gate that route could never fail, so it never blocked anybody.
A gate with no writer on the field it reads is not a gate. It is a comment.
Why this is the right shape for us specifically
The whole product is built on the idea that you should see what is happening rather than trust a status. It was strange to sell that and then show a new user nothing at all until they paid.
Now the demo is the product, running on their real history against a real job they chose. The pitch is no longer "trust me". It is "look at it, then decide whether you want it sent".
There is a second wall at the send itself, deliberately. Preparation being open does not mean an application ever leaves for free.
Where I am unsure
Two things I would take opinions on.
- Does watching it get written create enough desire, or does it satisfy the curiosity and end the session? I can argue both. I do not have enough data yet to know which one I am in.
- Should the prepared document be downloadable before payment? Right now it is not. Somebody will feel that as a bait and switch. I feel it as the difference between a draft and a submission.
If you have run a "watch it work, pay to finish" funnel, I want to know which side of that second question you landed on.
Solo founder, building an application tool. Not linking it here, the group asks us not to self promote, but happy to answer anything about the numbers in the comments.
"A gate with no writer on the field it reads is not a gate. It is a comment." — that line is going to stick with me.
We hit a version of this building an AI strategy tool: a validation step that was supposed to block a report from shipping if the source data was too thin. It always passed, because the thing it checked for had never actually been produced by any upstream step — there was nothing for it to fail on. Same shape as your bug: the gate existed, but nothing fed it a reason to close.
The "look at it, then decide" framing you landed on is the right instinct. We ended up doing something similar — instead of asking people to trust a market-size number, we show them the exact evidence (or the explicit "insufficient basis" flag when there isn't any) before they act on it.
On your open question: I'd lean toward showing the draft even before payment. The moment you hide the thing that's supposed to build trust, you're back to trust-me.
Letting people finish the work before asking for money is a good instinct, because by then they have something they do not want to abandon. Did completion rates on the draft step move at all after you shifted it?
Both your questions have the same root, and naming it answers both: your value is the send, not the draft. The 20-minute browser session driving a real hiring system is the expensive, defensible part. The document is cheap (you proved it, 1,200 tokens) and a commodity, ChatGPT writes a tailored resume too.
On Q2, don't make it downloadable, but not for anti-theft reasons. Let them download the doc and you've redefined the product as document-generation, a race to zero, given away the one thing that ISN'T your moat while your actual moat sits behind the wall. Non-downloadable isn't bait-and-switch, it's refusing to let a resume generator be your category.
Q1 is the same fork. Watching it get written creates desire only if the send still looks hard afterward. If submitting feels trivial once they've seen the doc, they copy it and do it themselves. So the demo shouldn't just show a clean document, it should show the twenty-minute grind you're about to do for them, the portal, the fiddly per-company fields. Reveal how annoying the send is, and desire goes up not down.
Does your written-application view make the send look easy or hard right now?
The zero-writer gate is the detail I would keep auditing, because it is the class of bug pricing walls hide. I would add one regression test: fixture a prepared application, assert the gate field is written before payment, and run it in CI, turning 'the wall had a bypass' from an incident into a checked invariant. On download: keep the export behind the send wall, but let users select and copy the visible draft without any limit. Clipboard friction creates anger, not conversion; the honest boundary is submission, which you already preserved.
The cost audit is the part more people should copy: you found the thing that felt expensive was 4% of a grant you were already giving away, and the pricing was built on a hunch instead of a number. On your first question — in my experience watching the work get done doesn't satisfy curiosity, it raises the standard. What kills conversion isn't seeing the output, it's seeing output that's obviously generic; if the draft is visibly built on their real history, the unfinished last step is exactly what people pay to close. On the second, I'd keep the download behind the wall but make the on-screen version fully readable. Copy-paste friction is a weak moat and it annoys the people who'd have paid; the honest wall is the send, which you already have. The thing I'd instrument is time-on-demo before purchase — if buyers watch less than non-buyers, the demo is doing persuasion, not satisfaction, and you can shorten it.
The shift from a paywall before the work to the send itself is interesting. Letting users actually see the application being built gives them something concrete to evaluate before deciding whether to pay.