Why we removed the sign-up wall from our 24-hour access, and what happened next

As CMO, my job is to remove everything that stands between a user and the moment they understand why the product is worth paying for.

For longer than it should have been, we had a wall built into the middle of that journey.

If you wanted 24-hour unlimited access to MachineTranslation.com, you had to create an account first. Sign up, verify, then pay. It is the standard SaaS playbook, and we followed it without questioning it hard enough — because on the surface, it makes complete sense. You need to know who you are giving access to. You want a registered user, not a one-time anonymous transaction. You want a relationship, not a receipt.

The problem is that logic falls apart the moment you apply it to the context in which users actually hit that paywall. They are mid-task. They translated something, hit a limit, and they want to keep going. They are not in an onboarding mindset. Every step you add between that moment and payment is a bet that the value of the step outweighs the users you lose to it.

We were losing that bet. This is the story of how we found out, what we changed, what broke when we changed it, and what I would do differently if we were building it from scratch today.

What the old flow looked like, and why we thought it made sense

The original 24-hour access flow required users to complete account registration before being redirected to the Stripe payment page. Fill in your email, set a password, verify the account, then pay.

From a product architecture standpoint, this was not arbitrary. It existed because 24-hour access is a subscription, not a guest checkout. The system needs to know which account to attach the access to, and it needs that account to exist before the payment is processed. Without it, there is no clean way to log users in after payment, serve them the full translation experience, or handle edge cases like a second session on a different device.

From a marketing standpoint, I also believed (not unreasonably) that registration before payment was a net positive. A registered user is someone you can email, re-engage, and move toward a monthly subscription. A guest transaction is a closed loop. Getting the account first felt like it served both the product and the growth strategy simultaneously.

That reasoning held well enough while the platform was early. As our data became more granular, the cracks in it became harder to ignore.

What the data was telling us that we weren't fully hearing

The signal we kept returning to was funnel drop-off at the registration step. Users who clicked to unlock 24-hour access and then did not complete the purchase.

When we mapped where they were leaving, the sign-up wall was a consistent exit point — not the only one, but a meaningful one. A few specific patterns made the problem concrete.

First, users who already had an account were hitting errors when they tried to register again. The flow did not recognise them as existing users and served them an email-already-exists error instead of routing them to a login. We were penalising our most engaged users (the ones who had come back) with a friction point that made the product feel broken.

Second, mobile abandonment during sign-up was disproportionately high. Filling out a registration form, setting a password, and verifying an email on a phone at the exact moment you want to continue translating is not a flow that people move through willingly. The sign-up screen on mobile occupies the full viewport. It signals a commitment that the moment does not call for.

Third, we were watching mobile users convert at a fraction of the desktop rate. Some of that gap is intent (mobile users are often in a lighter usage mindset) but the friction at registration was amplifying a gap that should have been narrower.

As CMO, what concerns me most is not any individual data point in isolation. It is when multiple signals point in the same direction over time and the organisation has not yet acted on them. That is the pattern we were in. The cumulative case for change was clear. The delay was in resolving the architectural question of how to remove the wall without breaking the subscription model underneath it.

The decision to remove the wall, and how we built the new flow

The architectural problem was real: if a user pays before creating an account, what account do you attach the payment to?

The solution was to flip the sequence. Stripe captures an email at checkout, that is the one reliable data point we have before account creation. We use that email to create an account automatically after a successful payment and auto-log the user in, so they land directly back in the translated result with full access already active. No registration screen. No verification step. No redirect.

The password question we handled by sending a setup link via email after payment. Users who want to return later on a different device set their own password at their own pace. Users who only need the 24-hour window and have no interest in a persistent account are not required to think about it at all during the moment of purchase.

What "bypass sign-up" actually means in practice

From the user's perspective: hit the paywall, click 24-hour access, land on Stripe, pay, return to the translation with full access already active. Four steps. No form in the middle.

From the system's perspective, the Stripe webhook confirms payment, triggers account creation using the checkout email, generates a session token, and logs the user in — all within seconds of payment completing. A welcome email with the password-setup link goes out in parallel.

What happened after we shipped it

The most immediate and expected outcome: mobile sign-up model visibility dropped. Users who would previously have abandoned during registration were now reaching the Stripe checkout page. The sign-up screen stopped being a door that a percentage of people did not walk through, because it was no longer in the path.

Subscriptions increased in the weeks following the change. We are careful not to attribute all of that to the flow change alone (pricing also shifted in the same period) but the directional signal was consistent with what we had modelled.

What I found more interesting than the headline metrics was the clarity the change created downstream. Once the registration friction was removed, we had much better visibility into the Stripe checkout page itself as a source of drop-off. Users who had not previously been reaching checkout were now reaching it, and some of them were not completing payment. That became the next problem to solve: checkout page experience, wording consistency between the paywall and the Stripe page, and whether embedding Stripe directly into the site rather than redirecting to it would improve completion rates.

This is how conversion work actually progresses. You remove one wall and the next wall becomes visible. Each layer of friction you eliminate surfaces the friction that was hiding behind it. From a marketing leadership perspective, that is exactly the dynamic you want — not because it means the work is endless, but because it means you are getting closer to a flow that reflects how users actually want to move through a product rather than how the architecture finds it convenient to process them.

What we'd do differently, and what we're still figuring out

If we were building this flow from scratch today, mandatory pre-payment registration would not be in it. Account creation belongs after value is delivered, not before. Most users who pay for 24-hour access and find the product genuinely useful will create a proper account naturally. Those who do not were unlikely to become long-term subscribers regardless. The registration step was costing us the former group without meaningfully protecting us from the latter.

What we have not yet resolved: whether to apply the same flow change to monthly Pro Plan subscriptions. The principle is the same — remove the wall, capture the email at Stripe, create the account post-payment. But the stakes are different. A monthly subscription is a longer relationship, the edge cases are more varied, and the cost of a poor experience during the signup moment is higher because the commitment the user is making is higher. We are letting the 24-hour data accumulate before making that call.

The broader principle I keep coming back to: every step you add between intent and payment is a bet. Sometimes the bet pays off — capturing a registration before payment gives you a marketing asset, and that is worth something. But in a high-intent, mid-task moment, the bet is almost always wrong. Someone who wants to finish translating a document right now is not in the mood to be onboarded. Get out of the way, take the payment, and earn the relationship after.

Try MachineTranslation.com — Pro Plan from $19/month · 24-Hour Unlimited Translations from $6

Pricing current as of May 2026 and subject to change.

About the author

William Mamane
Chief Marketing Officer, Tomedes
Connect on LinkedIn →