Portal adoption flatlines at 40% not because your product is weak—it's because passwords are friction. Every password reset email that lands in spam, every password forgotten on day two, every "I'll do it later" that turns into never: those are adoption kills. But replace password entry with a single SMS OTP? Adoption climbs to 80% in 48 hours. The difference isn't subtle. It's the difference between a tool your customers occasionally remember to use and a tool they default to. The mechanism is simple. The user lands on your portal, enters their phone number, receives a six-digit code via SMS, and logs in. No passwords to reset. No username to remember. No email client to check. The entire flow takes 90 seconds. Your job is to test three things: SMS delivery reliability, validation flow integrity, and the adoption lift itself. This playbook walks you through each test, shows you how to implement it in Orin, and proves the economics at ₹1 per login. Why passwords sabotage portal adoption Password-based login creates five friction points: Forgotten passwords: Users request resets. Reset emails land in spam or expire. Friction compounds. Multiple passwords: Users refuse to memorize another password. They reuse credentials or skip login entirely. Device friction: Mobile users have to switch apps to retrieve email, then return to complete the reset. Many drop off. Security theater: Password policies (min 8 chars, uppercase, numbers, special char) sound secure but force users to write them down or use the browser's insecure "remember password" feature. Cognitive load: Even one extra authentication step cuts completion rates by 15–20%. SMS OTP removes all five. The flow is synchronous: enter number, receive code, log in. No email required. No password policy burden. On mobile, the user sees the code in their SMS inbox without app switching on modern Android. On iOS, the code autofills if the device recognizes the sender. Adoption rises because friction falls. Test 1: SMS delivery reliability SMS OTP is only as good as the delivery rate. If 10% of codes don't arrive in the expected 30–60 seconds, your adoption gain evaporates. Test this before rollout. The test setup Pick two SMS providers: Twilio and AWS SNS cover 95% of SE Asia. Twilio is easier to integrate; AWS SNS is cheaper at scale. For this test, use Twilio. Cost: ~₹0.50 per SMS. Send 500 test OTPs across three time windows: Morning (8–10am), midday (12–2pm), evening (6–8pm). This catches carrier congestion patterns. Test three phone types: Prepaid (high volume, sometimes throttled), postpaid (faster), and data-only plans (should not receive SMS—this is your control). Measure three metrics: Delivery rate: percentage of OTPs that arrive within 60 seconds. Latency: median time from send to receive. Retry rate: percentage requiring a second OTP request. Pass/fail thresholds Delivery rate: ≥98%. Anything below 95% means your users hit retry buttons constantly and suspect the system is broken. Median latency: <10 seconds. Users begin to doubt the OTP arrived if they wait longer than 15 seconds. Retry rate: <5%. More than that, and users assume the portal is faulty. If Twilio fails this test in your region (unlikely in SE Asia, but possible on smaller carriers), switch to a local provider: Telnyx, Nexmo, or regional partners like Infobip. Test 2: Validation flow and brute-force resistance An OTP system is only secure if it resists brute-force attacks and rate-limiting. A weak OTP flow invites attackers to spam login attempts and lock out legitimate users. The validation rules you must enforce OTP length: Six digits (one million combinations). Four digits is too weak; eight is overkill. Validity window: 10 minutes. Longer than 10 minutes and users forget the code. Shorter and they retry unnecessarily. Attempt limits: Max five failed attempts per OTP. After five failures, revoke the OTP and force a new request. Rate-limiting: Max three OTP requests per phone number per 15 minutes. This stops bots from carpet-bombing phone numbers. IP-based blocking: If an IP address generates more than 20 OTP requests in one hour, flag it for review. If 100 in 24 hours, block it temporarily. Test the flow manually Request an OTP. Receive it. Attempt login with wrong code five times. Verify the OTP is revoked and you're forced to request a new one. Request three OTPs in rapid succession. Verify only the latest one works (older ones are revoked). Request an OTP, wait 12 minutes, attempt login. Verify the code is rejected as expired. Simulate an attack: write a script that requests OTPs from 50 different phone numbers in 60 seconds from the same IP. Verify your rate-limiter blocks the IP on the 21st request. Implement these rules in Orin's automations layer or in your backend if you're building custom. Do not skimp here. A weak OTP flow will be discovered and exploited within weeks. Test 3: Adoption lift measurement This is the real test. Does SMS OTP actually increase portal ad