One Forgotten Password, 22% of All Support Tickets
An e-commerce client came to us in month three. Nothing was broken: 22% of support tickets were "cannot log in," and most of those were people who had signed up with a messaging account and later signed up again by email — two accounts, two loyalty balances. The original quote read "membership system, lump sum, NT$45,000." The real cost came afterwards: merging duplicates, reconciling points, and support checking them one by one. The login page is the only page every user passes through, and it routinely gets the least planning time.
When It Fits, and When It Does Not
| Build your own account layer | Do not; use something off the shelf |
|---|---|
| Member records tie deeply to orders, points and permissions | You only collect leads — a form plus an email tool is enough |
| Website, app and admin all share one identity | One website, no app, no role separation |
| Tiered permissions (HQ, store, staff, dealer) | Fewer than 500 internal users — a workspace group will do |
| You need audit trails of who changed what, when | No compliance or audit requirement |
| You have been compromised, or you carry payments | Pure information site with nothing worth stealing |
Three Options Compared
| Option | Upside | Downside | Cost band |
|---|---|---|---|
| Self-built (Laravel Fortify + Sanctum) | Own the data, deep customisation, no seat cap | You build MFA, risk detection and auditing yourself | NT$120,000–320,000 build, then hosting only |
| Managed (Auth0 / Firebase Authentication) | Fast launch, social sign-in and MFA out of the box | Priced by MAU, steps up sharply with growth; data offshore | NT$60,000–150,000 build plus monthly fees |
| Platform built-in (hosted commerce suites) | Almost no development | Cannot share identity across systems; export limits | Included in platform subscription |
The decision line is simple: if identity serves one system, buy it; if identity spans three or more, build it. The usual failure with managed services is not price — it is getting users out two years later.
The Eight-Week Build
- Week 1 — Identity inventory (3 days): list every entry point and its identity source. Deliver an identity source matrix in Notion.
- Week 2 — Sign-up path design (4 days): choose one primary key (phone or email, not both) and define the social sign-in merge rules. Deliver a Figma flow plus a merge rules table. Skip this and you will create duplicates.
- Weeks 3–4 — Core build (8 days): sign-up, sign-in, password reset, verification, session and token management. Fortify for the base, Sanctum for mobile tokens.
- Week 5 — Social sign-in (4 days): LINE Login and Google OAuth; with an iOS app, Apple requires Sign in with Apple alongside them.
- Week 6 — Protection layer (5 days): login throttling, a bot challenge, Have I Been Pwned breached-password checks, unusual-location alerts.
- Week 7 — MFA and permissions (5 days): TOTP first, SMS OTP second, passkeys if the audience suits; roles via a permission package.
- Week 8 — Audit and launch (4 days): login event table, password change log, admin impersonation trail; deliver the runbook and merge SOP.
Real Cost Breakdown
- Development: base account layer from NT$120,000; social sign-in +NT$35,000; MFA +NT$45,000; granular permissions +NT$60,000.
- SMS OTP (most often missed): roughly NT$0.7–1.5 per message in Taiwan. 8,000 verifications a month is NT$5,600–12,000, or NT$70,000–140,000 a year. International is dearer; Twilio publishes per-country rates.
- Managed service fees: billed by monthly active users, usually free for the first few thousand, then stepping up rather than scaling linearly.
- Support load: password resets and duplicate accounts are typically the largest hidden labour cost in the first three months.
- Data clean-up: merging existing duplicates usually runs NT$40,000–150,000 depending on how dirty the data is.
- Annual maintenance: 15%–20% of build cost, covering OAuth credential rotation and library security updates.
Reality vs Expectation
- Expected: adding social login is a one-day job. Reality: the integration is a day; the merge rules take a week because they touch points and order ownership.
- Expected: stricter password rules mean more security. Reality: NIST SP 800-63B explicitly advises against forced periodic rotation and composition rules, favouring length minimums plus breached-password screening.
- Expected: just turn MFA on. Reality: without backup codes and a recovery path, higher adoption means more support calls.
- Expected: member data can be exported any time. Reality: managed services generally will not hand over password hashes, so migrating means a global password reset.
Five Traps and How to Avoid Them
- Making both phone and email unique. Users who change either get locked out. Fix: one primary key, the other a verifiable attribute.
- Merging social accounts on email. Some providers return relay addresses. Fix: key on the provider user id; treat email as a hint and confirm conflicts manually.
- Reset links with no expiry or reuse limit. Fix: 15-minute expiry, single use, and force sign-out of all devices after a change.
- Rate limiting by IP only. Credential stuffing is distributed. Fix: count per account as well, and screen against breached-password lists.
- Admin impersonation with no trail. Nobody can tell later whether the customer or support made the change. Fix: record operator, time and reason.
Success Metrics and 90-Day Roadmap
- Day 30: sign-up completion ≥ 75%; login failure rate < 8%; zero new duplicate accounts.
- Day 60: password-reset tickets below 5% of total; MFA adoption among payment-carrying members ≥ 30%.
- Day 90: one duplicate-account clean-up completed; anomaly alert false positives < 10%; a handover-ready identity architecture document.
Decision Checklist
- ☐ Can you name the unique identifier in your current system?
- ☐ Can one person arrive through three or more entry points?
- ☐ Is member data tied to orders or loyalty points?
- ☐ Do you have an iOS app? (If so, Sign in with Apple is required.)
- ☐ Do you already have duplicate accounts?
- ☐ Does support handle more than 30 login issues a month?
- ☐ Do you carry payments or monetisable points?
- ☐ Do you need admin impersonation?
- ☐ Any audit or compliance requirement?
- ☐ Might you replace the front end or add an app within two years?
- ☐ Is the annual SMS OTP budget allocated?
- ☐ Will someone be alerted before provider credentials expire?
Six or more ticks: build it. Three or fewer: buy it.
FAQ
Phone number or email as the primary account?
For consumer services in Taiwan, phone works better as the primary key: people change numbers less often than mailboxes, and it lines up with SMS OTP and delivery notifications. For B2B or cross-border services, use email, since the other party may have no local number. The point is to pick exactly one as unique.
Is MFA mandatory?
Recommended wherever there are payments, points or personal data access, but tier it: require a second factor for high-risk actions such as changing bindings, withdrawals or delivery details, not for ordinary browsing. Site-wide enforcement usually buys a drop in sign-ups.
How often should passwords be rotated?
Per NIST SP 800-63B, do not force periodic rotation unless there is evidence of compromise. A length minimum (12 characters or more) plus breached-password screening at the moment of setting is more effective.
Should we do passkeys now?
Worth a second phase if your audience skews young or app-first, but not as the only sign-in method, because device-loss recovery still relies on existing channels. The pragmatic order is password plus breach screening plus TOTP first, passkeys as an accelerator afterwards.
Next Step
ScriptWalker's Membership and Authentication Module build starts at NT$120,000, covering identity source inventory, merge rule design and the eight-week build. An audit and duplicate-account clean-up for an existing system starts at NT$45,000. If you only want to settle build-versus-buy, bring the checklist above to a free 30-minute call.
- Email: [email protected]
- Phone: 0916-224-047
- LINE: @ufv9089p