End-to-end signup experience across all entry points on app.qoruz.com. A broken OAuth path, a nuanced form-rejection pattern, and the design decisions that shape who gets in, and who walks away.
Qoruz's signup flow contains a chain of friction points that compound into user drop-off. At the center is a business-email-only registration policy whose enforcement timing varies across paths, with different implications for each.
On the Google OAuth path, the signup is completely broken due to a backend validation bug. Every user who clicks "Sign up with Google" hits a silent dead end with zero feedback. This is unambiguously a defect.
On the manual form path, the picture is more nuanced. Users fill out name, phone, and email before learning that public email domains aren't accepted. This could be a UX oversight, or it could be a deliberate lead capture strategy: the rejection modal surfaces a named Customer Success Manager with live contact options, turning a failed signup into a warm outreach opportunity. This analysis examines both interpretations and evaluates the tradeoffs of each.
The document walks through the signup experience as a user encounters it, identifies where and why users drop off, presents the case for and against the current design, and proposes alternatives that preserve lead capture benefits while reducing friction.
Qoruz has a qualification requirement: only users with custom domain email addresses (business accounts) can sign up. This is a reasonable and common B2B SaaS policy. The issues in the signup flow fall into two distinct categories:
The OAuth signup path is broken for all users due to a missing reCAPTCHA token. This is a bug. No design intent can explain a 422 error with zero user feedback.
The manual signup form collects name, phone, and email before revealing the business-email restriction. Whether this is an oversight or a deliberate lead capture strategy is a question worth examining, because the answer changes what the right fix looks like.
The Google OAuth signup is non-functional due to a missing reCAPTCHA token in the API payload. The backend returns a 422 error. The frontend silently swallows it. The user sees no error, no message, no indication of failure. The page simply remains unchanged.
This was tested across four separate attempts: two Google accounts (personal Gmail and Google Workspace), two browser modes (normal and incognito), two sessions hours apart. The failure is 100% reproducible and account-agnostic. Full technical details are in the companion bug report.
The compounding irony: Even if this bug were fixed tomorrow, Google OAuth with a personal Gmail address would still fail because Qoruz rejects public email domains. But the user would never know this before attempting to sign up, because nothing on the signup page communicates the business-email requirement in the context of Google OAuth.
Any user who attempts Google OAuth signup will fail silently. A technically inclined user might try once more, then switch to the manual form. A typical user will conclude the product is broken and leave. There is no recovery path presented.
The user fills out three form fields (name, phone, email) and submits. The backend rejects the public email domain, and a modal appears explaining the restriction: "To access Qoruz, please sign in using your company email address. Public email domains (like Gmail or Yahoo) aren't supported at the moment."
The form label says "Business email" which is a hint, but the placeholder text says "Enter your business email" without explaining what qualifies. Users routinely interpret "business email" as "the email I use for business" rather than "an email on a custom domain."
The rejection modal is worth examining closely. It doesn't just reject the user. It surfaces a named Customer Success Manager (Eswaran Sundareshwaran) with a live "Online" status indicator, a "Send Email" button, and a "Copy Mail" option. The text reads: "Eswaran is here to get this sorted for you, right away!" This is a lead capture mechanism. By the time this modal appears, Qoruz has the user's name, phone number, and email. The CSM contact converts a rejection into a human touchpoint.
It's a UX friction point. Users invest effort before being told their input is invalid. The effort makes the rejection feel punitive rather than informative.
It's a lead generation strategy. The sunk cost of filling three fields makes the user more likely to engage with the CSM rather than bounce. A user who typed in their Gmail might still work at an agency that uses Workspace. Now Qoruz has their contact details and a warm reason to reach out.
Users who see this modal split into three groups: those who switch to a work email and retry (conversion), those who contact the CSM (warm lead), and those who leave (lost). The question is whether the warm leads captured through this flow justify the users lost due to the late disclosure. That depends on Qoruz's internal data on CSM follow-up conversion rates, which are not externally visible.
This path works. It's the only one that does. But the user only reaches it after potentially failing at Path 1 and Path 2 first.
Qoruz enforces its business-email requirement at different points across different paths:
| Signup Path | When User Learns About Requirement | Effort Already Invested | Category |
|---|---|---|---|
| Google OAuth (broken) | Never (silent failure, no error shown) | Selected account, granted OAuth consent | Bug |
| Google OAuth (if fixed, personal email) | After OAuth + API call | Selected account, granted OAuth consent | Design gap |
| Manual form (personal email) | After filling 3 fields + submission | Name, phone, email entry | Bug or deliberate |
| Manual form (business email) | N/A (succeeds) | Name, phone, email entry | Working as intended |
The Google OAuth failure is unambiguously a bug. No lead capture occurs. No CSM modal appears. The user gets nothing. There is no possible design intent behind a swallowed 422 error.
The manual form's late enforcement is the one that could go either way. If it's deliberate, the rejection modal with the CSM contact is the intended recovery path for unqualified users. If it's not deliberate, the modal's lead capture elements are a happy accident layered on top of a UX gap.
One principle holds: the Google OAuth path must either work or fail with clear feedback. It currently does neither.
Assuming the manual form's late-stage email rejection is an intentional lead capture strategy, the tradeoff looks like this:
Contact details (name, phone, email) from high-intent users who visited the signup page and filled out the form.
A warm touchpoint via the CSM modal. The sunk cost of three filled fields makes the user psychologically more likely to engage with the CSM than to bounce.
The user might work at a company that uses Workspace, making them a qualified lead whose personal email was simply the wrong entry point.
Users who don't contact the CSM and leave with a negative first impression.
Trust erosion from users who feel the form wasted their time by not disclosing the restriction upfront.
Any word-of-mouth damage from users who tell colleagues "I tried to sign up for Qoruz but it doesn't accept Gmail."
Potential regulatory considerations around collecting contact details before revealing that the service isn't available to the user.
The Google OAuth path produces none of the lead capture benefits. A user who clicks "Sign up with Google" and fails silently never sees the CSM modal, never has their contact details captured, and never receives any recovery path. If the manual form's late enforcement is a deliberate strategy, the OAuth path's silent failure is actively undermining it by losing users before they ever reach the form.
Let the OAuth path fail gracefully by showing the same "Work email required" modal with the CSM contact. This preserves the lead capture benefit for OAuth users too. It also collects the user's name and email from the Google JWT (richer data than the form provides, since it's verified by Google). Right now, the OAuth path captures zero data from failed signups. That's a missed opportunity regardless of the design philosophy.
The OAuth signup button is prominently placed on the signup page. It's a familiar, low-friction entry point that users actively prefer. Industry data shows social login increases signup conversion rates by 20–35% on average, with Google accounting for 75% of all social logins across platforms. Every single user who clicks this button on Qoruz today will fail silently and receive zero feedback.
The only users for whom Google OAuth could legitimately work (given the business-email policy) are Google Workspace users. Google Workspace has over 6 million paying business customers as of 2025. Among U.S. startups, over 90% use Gmail as their primary email platform, with a significant share on Google Workspace. These are exactly Qoruz's target users: marketers and agencies at companies already running their email on Google. The OAuth path should be their fastest route in. Instead, it's broken.
The Mixpanel integration on the signup page operates at the anonymous device level. Based on the console output observed during testing, no explicit event tracks for "Google OAuth clicked" or "OAuth callback received" were visible. If OAuth-specific funnel events are not being tracked, Qoruz has no visibility into how many users attempt Google OAuth, how many fail, or where in the funnel they drop.
B2B SaaS visitor-to-trial rates average 2.1–7.1% depending on sector. For a platform like Qoruz driving traffic through SEO (their UTM params confirm utm_source: "SEO", lead_source: "Inbound - SEO"), every signup page visitor represents meaningful acquisition cost in content, SEO effort, and time. Industry research consistently highlights that signup flow friction is one of the primary drivers of top-of-funnel drop-off, and users who encounter silent errors have near-zero retry rates. Each lost signup represents not just an immediate conversion loss but wasted CAC.
Where: Signup page, above the fold.
Neither the page header, the form description, nor any visible element states that a custom domain email is required. The form label "Business email" is ambiguous. Users interpret this differently depending on context.
If unintentional: Add a single line of clarifying text near the email field: "Use your work email (e.g., you@company.com). Public email domains like Gmail aren't supported." Alternatively, validate the email domain client-side and show an inline hint the moment a user types @gmail.com.
If intentional (lead capture): Keep the current flow but ensure the rejection modal always appears (including on the OAuth path). Consider adding Mixpanel event tracking on the CSM buttons to measure conversion rate.
Where: Signup page, below the manual form.
The "Sign up with Google" button is available to all users regardless of their Google account type. There is no indication that only Workspace accounts are supported. A user with a personal Gmail account will complete the entire OAuth consent flow before being rejected (or, currently, silently failing).
Where: Frontend, post-OAuth callback.
When the /api/register call returns a 422 (or any non-2xx response), the frontend does nothing. No error toast, no modal, no inline message. The user has no recovery path. They don't know what went wrong, so they can't correct it. The only rational conclusion is "this product is broken."
Where: Manual signup form, after submission.
When a user submits the form with a personal email and sees the "Work email required" modal, the psychological cost is that they've been told their first attempt was wrong after investing effort. The improvement (regardless of intent) would be to ensure the CSM engagement is tracked and the recovery path pre-populates the user's details.
Where: Signup page, testimonial section (right panel).
The react-responsive-carousel component fires renderThumbs errors in an infinite loop because showThumbs is not set to false. Each iteration triggers a setState call, causing continuous re-renders. The console accumulates hundreds of warnings within seconds. This also causes google.accounts.id.initialize() to fire multiple times.
The right redesign depends on whether late enforcement is deliberate or not. Below are two approaches.
The first thing the signup page asks for should be the work email. One field, one button ("Continue"). This sets the expectation that a work email is needed, allows client-side validation before any other effort, and matches the pattern used by Airtable, Notion, and Slack.
Below the email field, show the Google OAuth button with a clarifying note: "Sign up with your company's Google Workspace account." After OAuth completes, check the hd (hosted domain) claim in the JWT. If present, proceed. If absent (personal Gmail), prompt the user for a work email, pre-filling their name from the JWT.
Only after the email is confirmed as a valid business domain should the form expand to collect name and phone number (or pull these from the OAuth JWT). This ensures no user invests effort in fields that will be discarded.
When a Google OAuth signup fails, show the same "Work email required" modal with the CSM contact. Extract the user's name and email from the Google JWT and pass these to the backend as a captured lead. Right now, the OAuth path captures zero lead data from failed signups.
Add Mixpanel events for: modal shown, CSM "Send Email" clicked, CSM "Copy Mail" clicked, modal dismissed without action. Without this data, there is no way to evaluate whether the late enforcement strategy is net positive.
When the modal appears, it should pre-fill a contact form with the user's name, phone, and email. This reduces friction on the recovery path. Currently, the user has to manually email or copy the CSM address.
Always show feedback on failure. Every API call that can fail must have a corresponding user-facing error state. No silent failures. No spinners that spin forever. No forms that simply stop responding. This is not a design philosophy question. It's a baseline product quality requirement.
| Priority | Issue | Fix | Effort |
|---|---|---|---|
| Critical | Google OAuth broken (missing reCAPTCHA token) | Backend: skip reCAPTCHA when is_google_login: true |
Low |
| Critical | Silent error on OAuth failure | Frontend: catch non-2xx, show contextual error | Low |
| Critical | OAuth failure produces zero lead capture | Show CSM modal on OAuth failure, capture name/email from JWT | Low |
| High | OAuth path has no email-type qualification | Check JWT hd claim, prompt for work email if absent |
Medium |
| Low | Carousel rendering loop | Set showThumbs={false} |
Trivial |
| Low | Duplicate GSI initialization | Initialize outside render cycle | Low |
| Low | Mixed content warnings | Update S3 URLs to HTTPS | Trivial |
| Rec. | No analytics on OAuth attempts or CSM modal engagement | Track signup_google_clicked, oauth_callback_received, register_api_error, csm_modal_shown, csm_email_clicked |
Low |
| Priority | Issue | Fix | Effort |
|---|---|---|---|
| High | No upfront email domain communication | Inline client-side domain validation + clear copy | Low |
| Medium | Manual form rejects after full input | Move email to first field, validate domain before expanding form | Medium |
| Priority | Issue | Fix | Effort |
|---|---|---|---|
| High | CSM modal engagement is unmeasured | Add Mixpanel tracking on all modal interactions | Low |
| Medium | CSM contact path has friction | Pre-populate contact form with user's already-entered details | Low |
This analysis is based on direct, hands-on testing of the Qoruz signup flow conducted on 3 May 2026. Every issue documented here was personally encountered, reproduced, and verified through browser DevTools (Console, Network tab). The companion bug report contains the full technical evidence including decoded JWT payloads, HTTP request/response pairs, and timing profiles.
The issues fall into two categories. The Google OAuth bug and silent error handling are unambiguous defects that affect every user who attempts that path. The manual form's late enforcement of the business-email requirement is either a UX gap or a deliberate lead capture strategy. This analysis presents both interpretations and offers recommendations for each, because the right fix depends on intent that only the Qoruz team can clarify.
What is clear in both cases: the Google OAuth path currently serves neither goal. It doesn't convert users (broken), it doesn't capture leads (no modal shown), and it doesn't provide feedback (silent failure). Fixing this path is the highest-leverage improvement regardless of the broader design philosophy.