At CoinDesk, we once had to add verification to the checkout for our conference tickets, and roughly 60 to 70 percent of people dropped off at the shopping cart. We moved verification later, to the point where someone got their event ticket, and we didn't see nearly as high a drop-off. A few years later, that lesson was the one I brought to Tallo.
Tallo needed email verification. Tallo's parent company required proof that users owned the email address on their account. The hard part was the audience.
Why Verification Was Hard for This Audience
Tallo is a career platform for teens and young adults, and a lot of them sign up with a school-issued email address. Schools run aggressive spam filters, and those filters catch legitimate mail, including verification emails. Some students don't have a personal email at all, and school addresses stop working after graduation. Phone verification wasn't a reliable fallback either, because few users gave Tallo a phone number and some younger students don't have one they can use at school.
So the obvious version of verification – stop people mid-sign-up, send them to their inbox, and wait for them to come back – would have stranded exactly the people Tallo most wanted to keep. If the email lands in a school spam folder, that person literally can't verify, and they're gone. It's also an audience that rarely comes back after a bad first experience.
That was the tension. A security requirement nobody could ignore, and a sign-up flow a young audience would abandon.
Picking Up a Project Without an Owner
The project had been discussed for months without much movement. In January, a long meeting ended with no clear owner, so I took it on. I'd do the product work, design would take the experience, and platform engineering would build it.
A Tallo product lead had proposed a soft gate: let people create an account and use the product, and ask for verification later. I want to be clear that the idea was theirs. My contribution was backing it with what I'd seen at CoinDesk and then turning it into something a team could build.
Gating Only What Other People Can See
The soft gate needed a rule for what would be gated, and I proposed one question: is this action visible to other people?
Reading, searching, taking assessments, saving jobs to a private profile, following employers, and applying on outside sites all stayed open. Posting in the community, commenting, liking posts, following another person, making a profile public, and applying through Tallo all required a verified email.
That test came straight from the risk. Email verification exists here to stop someone from creating an account that represents somebody else. A fake account that only reads job listings doesn't hurt anyone. A fake account that posts under a real student's name, or fills a public profile with junk that a potential employer reads, does real harm to a real person. So the gate went where that harm happens.
It also meant the security level matched the sensitivity of what was being protected. Email verification isn't a strong security control on its own, so gating everything behind it would have cost sign-ups without stopping anyone determined to misbehave. Gating public actions put the friction where it actually protected people.
Putting the Friction as Late as Possible
Where the gate sits matters as much as what it covers. Someone new to a product makes a series of small commitments – they create an account, explore a bit, save a job, take an assessment – and each one makes it a little more likely they'll stick around. Introducing friction before those commitments is how you lose people, so the gate shows up only when someone tries one of the public actions, after they've already gotten something out of Tallo.
The gate itself is a prompt, not a wall. When an unverified user tries a gated action, a modal explains that they need to verify their email to continue, shows a masked version of the address on file, and sends the verification email with a hint to check the spam folder. The copy was written to be helpful, not punitive: a one-time step, not an "access denied."
The email carries both a link and a one-time code. A lot of young people sign up on their phone and check email somewhere else, and the code lets them verify from whatever device has their inbox open.
Writing the Epic and Holding the Scope
I wrote the epic and its stories, with one story per gated action, plus the modal design and copy. I defined success metrics for verification rate, how often people hit the gate, how many verified once they did, and a guardrail to watch whether account creation dropped. A security project that quietly costs a product its sign-ups isn't a success, even if every box gets checked.
My working style on a project like this is to own the who, the what, and the why, and leave the how to engineering. Engineering chose how to build the verification service, and I held the line on scope.
Holding scope meant cutting some things that looked like they belonged. Joining community groups was part of onboarding, and gating it would have meant reworking onboarding, which wasn't something the team could take on in a month. Following employers was tied to a sign-up flow that would have had to be pulled apart. Neither carried the same risk as following a person, which notifies that person, so both stayed open.
Questions That Came Up During the Build
A couple of decisions changed as the team built it. The early assumption was that people who signed in with a social account had already proven their email. When I looked closer, that didn't hold – a social login doesn't reliably prove someone owns a particular email address – so social sign-ins went through the same verification. Changing your email address also resets verification, since the point is proving you own the address on the account right now.
The web version shipped about two months after that January meeting, and mobile followed with support for opening the verification link straight into the app. It's still live.
Measuring It After Launch
A few months after launch, I went back to the verification funnel to see where people were stopping. Most people who hit the prompt closed it without asking for an email, and the analysis also turned up a gap: new accounts weren't getting a verification email when they signed up, so the gate was usually the first time anyone asked. We added a verification email at sign-up so people could verify before they ever needed to.
That's the part of the work I'd want any team to keep. A gate isn't finished when it ships. It's a hypothesis about where friction belongs, and the only way to know whether you put it in the right place is to look.
What I'd Tell a Team Facing a Security Requirement
Your security level should match the sensitivity of what you're protecting. So the first question I'd ask about any security requirement is what it's actually protecting against, and then I'd put the friction there and nowhere else. At Tallo it was impersonation, which only matters when other people can see what an account does. Once that was clear, the design mostly followed.
FAQ: Soft Gates and Email Verification
What is a soft gate for email verification?
A soft gate lets people create an account and use most of a product before they verify their email. Verification is required only for specific actions, which at Tallo meant the ones other people can see, like posting, commenting, following a person, or making a profile public.
Why not just require verification at sign-up?
Because many people never come back from the inbox. For an audience that signs up with school email behind aggressive spam filters, a verify-first flow would have blocked legitimate users before they ever saw the product. A soft gate asks later, after people have a reason to stay.
How do you decide which features to gate?
Start from the risk the verification is meant to address. At Tallo, that was someone creating an account that represents another person, so the test was simple: is the action visible to other people? Private actions stayed open, and public ones required a verified email.
Related Case Studies
- Fixing the Consensus 2024 Ticket Checkout at CoinDesk – where I first learned what verification in the wrong place costs.
- Building a Career Scorecard and Job Recommendations for Career Starters at Tallo – designing for the same skeptical young audience.
- Unsticking Tallo's Stalled Job Page Migration – another project that needed someone to hold the scope line.
- Defining Tallo's Resume Builder – the same rule of never acting on a student's behalf without asking, applied to resume import.