We moved the paywall off the draft and onto the send

The recording signature is the useful part, and I had not thought to write it down as a signature. Reveal completes, scroll back up, hover the button, bounce off the wall. That is countable. What I had instead was a debate with myself, which is exactly what you are warning against.

One trap I want to name before I go and do it: I will only watch the recordings I know how to find, and the people who left before the reveal finished are the least likely to end up in a session I think to open. So I am picking the sample by entry point, not by outcome. Otherwise I am reading my own selection back to myself and calling it evidence.

Your download argument is better than the one I had. Mine was a vague worry about people taking the artifact and going. Yours is that the lock is the instrument. Pay to download and pay to send are two different customers, and the wall is the only place they separate. That turns it from protection into measurement, which is a much easier thing to hold to when someone asks me to unlock it.

The broken chat widget story lands. Every physical cause I have found has been embarrassing in the same way, and none of them survived contact with a recording.

That line is doing a lot of work for me too, so I am glad it travelled.

The version we run now is the useful part: when a check is added, the first question is who writes the field it reads. If nothing does, it is not a gate. That one question has caught three more since, before any of them shipped.

It generalised further than I expected. It is the same rule that decides when an application counts as sent. Our agent does not get to mark its own work complete by reading back what it typed. It counts when the employer's own system confirms receipt, because that is the one signal in the chain we did not generate. Every tool in this category can tell you it clicked submit. Almost none can tell you the company received anything, and that gap is the whole product.

Yours sounds like the harder version, since a thin-data report still ships and still looks finished. Did you end up putting a writer behind the field, or asserting on something the pipeline could not fake?

Good question, and the honest answer is that the sample is still young, so I will give you the mechanism rather than a number I would have to walk back.

What I can already see is that the drop-off moved to a place where it means something. Before, people left with nothing on screen, so I could not tell disinterest from confusion. Now they leave holding a finished application written against a posting they picked, with their own history in it. That is a much better place to lose someone, because what they saw is measurable and I can improve it.

The bet underneath it is the one I would make again. Watching the work get done is more persuasive than any promise I could write about it, and it turns out to be cheap to give away. The expensive part was never the document. It is the twenty minutes of a real browser session driving a real hiring system, and that sits behind the wall where it belongs.

"Your value is the send, not the draft" is the cleanest statement of it I have read, and it answers the second question by dissolving it rather than debating it. You are right, and it is what we already do.

Where I would take it one step further. The send is defensible because it is unpleasant to build, but the thing that actually compounds is what happens after it. We treat an application as sent only when the employer's system confirms receipt, across the twelve ATS platforms we cover. Not our click, not a thank-you page, their receipt.

That is a harder moat than the browser session, because copying it means choosing to report a failure where a competitor reports a success. Most of this category has built its marketing on a number that requires never looking. Once you can see which applications silently never arrived, you cannot go back to counting clicks, and neither can your customers.

Would you rate that as durable, or as a lead with a clock on it?

Written and in CI, and you framed it better than I did: it turns an incident into an invariant, which is the only kind of fix that survives the next person refactoring near it.

On the clipboard, completely agree and we do it your way. The visible draft is fully readable and copyable, no friction, no tricks. The honest boundary is the send and we already have it, so a second weaker one only annoys people who were going to pay.

The useful generalisation from it: the test worth writing was not "does the gate work", it was "can this field ever be null here". That second question is the one that scales, and it is the same shape as the question the product answers for users. Not "did we click submit", but "is there any state in which the employer received nothing". That is the check almost nobody in this category runs, and it is why we can show you an employer confirmation instead of a green tick we drew ourselves.

Time-on-demo before purchase is the sharpest instrumentation idea I have had on this thread, and it inverts what I would naively have measured. If buyers watch less than non-buyers, the demo is persuading rather than satisfying, and it should get shorter. That is going on the list.

Your first-question answer matches what we are seeing. Watching the work get done raises the standard rather than satisfying the curiosity, and it only works because the draft is visibly built on their real history against a posting they chose. Generic output would kill it instantly, which is exactly why opening the draft improved our writing more than any internal push for better writing ever did. It put the quality bar in front of the customer.

The bit that surprised me: the unfinished last step turns out to be the strongest state in the funnel. A complete application you cannot send yet is more motivating than either an empty page or a finished download, because the only thing left is the part we are actually good at.

"Concrete to evaluate" is the part I would underline, because it quietly changed what we have to be good at.

When the wall sat in front of the work, the only thing a new user could judge was our copy. Everything they saw was a promise about what would happen after they paid. Now the first thing they see is a document with their own history in it, aimed at a posting they chose, and it either reads like them or it obviously does not. That is a much harsher test and I think it is the correct one.

The part I did not expect is what it did to us internally. A generic-sounding sentence used to be a quality issue we would get around to. Now it is a conversion bug, because it is on screen before anyone has paid anything. Opening the draft improved the writing more than any amount of me asking for better writing did.

What I am still unsure about is whether the concrete thing has to be unfinished to work. Right now the document is complete and only the send is locked. There is an argument that a finished document satisfies the curiosity and ends the session, and an argument that a finished document you cannot send is the most motivating state a person can be in. I lean to the second, and I do not have enough of a sample to say it rather than believe it.