Bits and Pieces Part 4: Just Click, Blink, You're In

It’s not a sudden stroke of genius.It’s slow, painful attrition. I'm watching users churn before they even sign up. Not just on my app, everywhere. Look around. People want *frictionless access* to everything, and rightfully so. If you’ve ever watched someone try to sign up for a course using their tiny phone on 2G internet, you know: the enemy isn’t bad design, it’s too much design. Every extra input field becomes a reason to quit. There’s something deeply offensive about filling out another signup form in 2025. It’s not even the time it takes, it’s the audacity of it. You’re telling me to enter my email, confirm my password (twice), solve a CAPTCHA, click a verification link in my inbox… just so I can maybe look around your app? So I'm tracking user intent vs user action.Someone clicks “Sign Up.” Great. That’s intent. But then they see six fields… and drop off halfway. That’s failure. But it’s not their failure, it’s ours. We built the wall. They just refused to climb it. The Button RevelationI realized: we don’t need a better form. We need no form — call me crazy. Just one button. And not just any button, a trusted one. Something users already recognize. Something their browser autofills. Something their device already authorizes. Google. Obviously. But just slapping a “Continue with Google” button isn’t enough. You have to understand why it works. Google Sign-In is just the costume. The real actor underneath? OAuth 2.0. That’s the protocol. The handshake. The reason it’s secure, portable, universal. You’ve just signed up. Great. Now what? Most websites just… stop. Like a cab driver slamming the brakes two blocks before your actual destination and then expecting a five-star rating. You’re left standing there with a fresh user account and zero direction, like someone handed you a gym membership and no clue what a deadlift is. That kind of design makes my eye twitch. So I'm fixing it!I'm wiring up my own modal system — basically a pop-up interface from a video game, backed by a Web Token, powered by my database state, to track one thing: did this user make a decision?That’s where Aula’s onboarding ends. And behavioral insight begins.The idea is simple: signing up should feel like hitting the jackpot. A toast shows up right after the 200 OK lands, flashing "Account successfully created”, animated with a countdown bar, then vanishes after 2 seconds like it was never there. Boom.Modal takes over. Two roads diverge: "Do you want to create a classroom, or just browse?"No backend engineering degree required, just a clean fork in the user journey. Visually intuitive. Programmatically deterministic. Use either the Google Sign-In option or the traditional email/password combo. Both wired. Both clean. Let’s make the dream real.We need one button. Not metaphorically. Literally. A single, elegant button that skips the bureaucracy and just logs you in. That's the dream. And dreams, as I’ve found, start with a problem and end in documentation. The problem? User drop-off. The solution? After chasing it through forums, GitHub issues, and open tabs that threatened to crash my browser… OAuth.OAuth isn’t new, but understanding it feels like solving a Rubik’s cube with the lights off. It’s the invisible contract that lets one service (Google, Facebook, GitHub) vouch for you on another (mine). But you don’t ask Google directly, you use a layer. That’s where Auth.js came in — a framework so clean it felt like cheating. Auth.js didn’t just give me OAuth. It gave me control.Here’s what that really means:Fine-grained callbacks — secret trapdoors that let you whisper logic into the login pipeline. “Tag this user with `hasOnboarded: false` before anything else happens.” That kind of Jedi-level precision. JWT support — we’re not babysitting sessions in server memory like it’s 2012. Tokens carry everything, user ID, timestamps, secret, like a digital carry-on. Stateless. Scalable. Slick. Provider system like Legos — want Google? Snap it in. GitHub tomorrow? Slot it in. No duct tape. No voodoo. Just clean, declarative config. The docs became **scripture**. You open them expecting chaos. You get divine revelation. Install the package — that’s the ceremonial door knock. Create your `auth` config file — the sacred gatekeeper, the programmable customs agent. Every login, every callback, filtered through one chokepoint. Set your strategy. We picked JWT — tokens over sessions, always. Pick your providers. We picked Google — fast, familiar, trusted. But knowing the whole OAuth pantheon is one config away? Comforting. Then the final ritual: you dive into the Google Cloud Console, which is less “console” and more hostile UI from 2014. You fill out your consent screen, name your app, and receive your Client ID and Client Secret, your passport to the ecosystem. You put them where they belong: your `.env`. Not your code. Never your code. Because security is mostly just not putting things where they don’t belong.Now your app speaks OAuth. When a user clicks “Sign In with Google,” it’s not just a UI event, it’s choreography. Your app hands them off. Google verifies. Hands them back. Credentials intact. Identity verified. All of that, millions of lines of infrastructure, triggered by one button. And that button? Surprisingly simple. It just calls a function: "Start Google login.” It succeeds, returns a session, and if the session exists? Redirect to dashboard. No middle forms. No confirmation emails. No friction. Just click, blink, and you’re in. Then there was the rogue flow.The traditional email/password signup worked fine. It was predictable. We owned the state. We owned the flow. When a user hit “Sign Up,” we could fire off a toast, start a timer, and trigger the modal like a cinematic cutscene. But Google OAuth? It skipped the frontend entirely. Dropped users in through the backdoor. It was clean, fast, and *completely outside* our visual pipeline. So we are reverse-engineering the same feel, the same joyful little UX illusion, for OAuth signups. And everything became a "state game". I don’t mean mental state. I mean literal React state. Booleans. Flags. Truths. Lies. Timing. Invisible logic that controls everything. First, the database needed to remember something the frontend could never guess: had this user ever onboarded?That meant adding a boring little field to our Prisma schema: `hasOnboarded: Boolean`. Not sexy. But critical. Because Google Sign-In never hits `/signup`, we had to store that truth somewhere deeper. That truth lives in the JWT.We are hijacking the `jwt` callback, the sacred little Auth.js hook that fires when a session is created. If the user is new, we tag them: `hasOnboarded: false`. That flag is passed into the token.We almost missed the part where we were actually going to update the hasOnboarded and change its value by creating a rest api patch and updating it whenever the user clicks on either "continue browsing" or "create classroom" Then into the session. Then to the frontend. The frontend reads it. And reacts.But timing still matters. We wanted a toast, a tiny, satisfying “Account successfully created” flash, to show up right after signup, then vanish like confetti. Not clingy. Just celebratory. We used `setTimeout`. Mount the toast. Start the 2-second timer. On timeout? Unmount the toast. Trigger the modal. But timers are sneaky. If the component unmounts early, or if `showToast` toggles too soon, we risk a memory leak or, worse, a rogue modal flash on re-render. So inside `useEffect`, we added a cleanup function that calls `clearTimeout`. That was the missing puzzle piece. Before that? One user reported the modal showing up *twice*. A late-night console.log autopsy traced it to, you guessed it, a dangling timeout. Fixed it. Cleaned it up. Now the toast lifecycle feels natural. Declarative.You sign up. Toast shows. It fades. Modal enters. You choose a path. The journey begins. All of this was possible because we treated the modal and toast as dumb components, visual puppets controlled by smart parents. `showToast` and `showModal` are booleans in the parent component. Passed down as props. The toast doesn’t know what `showToast` means. It just listens. Same with the modal. Handlers like `onClose`, `onContinue`, `onCreateClassroom`, they’re passed down like mission instructions. The modal doesn’t need to understand them. It just executes. Routing? Logic? That lives upstairs, where router.push(...)` lives. That’s how we rebuilt onboarding to feel unified, whether it came from a traditional form or a clean Google glide-in. At the heart of all this: Did the user just sign up? Or are they returning?If you can’t answer that, you can’t tailor the experience. You’ll either nag veterans with modals they don’t need or ghost rookies who need direction. So we built the whole system to detect one exact moment: The user’s first successful login.That’s all onboarding ever was, not just authentication, but affirmation. You belong here.We built Aula to get out of your way. And get you in. Fast.

Other insights from Matthew Okadinya

Referral Earning

Points-to-Coupons