DEV Community

Ujjawal Tyagi
Ujjawal Tyagi

Posted on

Build vs Buy: Authentication for Indian D2C Apps

#architecture #backend #security #startup

Auth0 costs ~$0.023 per active user per month at the volumes most Indian D2C startups operate at. For a brand at 100,000 MAU that's ~$2,300/month. For a 1M MAU app, it's ~$23,000/month. Which is fine if your gross margin per user is $5+. It's not fine if your average customer spends ₹300 a month on milk subscriptions.

This is the calculation that drives most of our Xenotix Labs backend decisions. Build the auth system, save the recurring fee. Buy the auth system, save 4 weeks of engineering. The right answer changes by company, and we've made both calls. Here's the framework we use.

What auth actually has to do for an Indian D2C app

  • Phone-OTP login (the default for India, not email/password)
  • Email/password as a fallback for older / NRI users
  • Social login (Google primarily; Apple for iOS users with iCloud accounts)
  • Magic link via WhatsApp or email
  • Session management with refresh tokens
  • Multi-device login + remote logout
  • Account recovery via the original phone OR email
  • Rate limiting on OTP requests (a single phone shouldn't be OTP-bombed by attackers)
  • DPDP Act compliance (consent storage, data retention, deletion requests)
  • Audit logging for compliance

If your auth provider doesn't natively support all of those, you're paying their monthly fee AND building chunks of auth on top. Worst of both worlds.

When to buy (Auth0, Clerk, Supabase Auth)

Buy when one of these is true:

  • You're under 50,000 MAU and time-to-launch beats running cost
  • Your team has zero security engineering experience and you need someone else to take responsibility for the basics
  • You need SSO/SAML for B2B customers (rolling SAML yourself is an unforced error)
  • You're integrating with HRIS, IDPs, or other enterprise identity systems

The real reason to buy isn't "auth is hard." It's that good auth is hard — password-spray rate-limiting, breach-list checks, device fingerprinting, ATO detection. A modest team will not match what Auth0 or Clerk does on those.

When to build

Build when one of these is true:

  • Your unit economics can't absorb the per-MAU fee at your projected scale
  • You need OTP delivery via Indian SMS gateways (Auth0's global pricing models are wrong for Indian SMS volumes)
  • You need WhatsApp OTP, which is often cheaper than SMS in India and which most non-Indian providers don't natively support
  • You need consent flows specific to DPDP Act / state regulations
  • You're operating at 1M+ MAU and your fee is a six-figure-per-month line item

What "build" actually means

It does not mean writing JWT signing from scratch. It means:

  • Use a battle-tested library for password hashing (Argon2 via your language's standard wrapper)
  • Use jsonwebtoken or your stack's standard JWT library for token issuance
  • Use a vetted OTP provider (MSG91, AWS SNS, or WhatsApp Cloud API for Indian volumes)
  • Build the orchestration: registration flow, login flow, OTP issuance/verification, session management, refresh tokens, password reset, social login OAuth dance
  • Build the security perimeter: rate limits, lockouts, account-takeover detection, breach-list checks (haveibeenpwned k-anonymity API)
  • Build the compliance layer: consent timestamps, deletion workflows, audit logs

For a senior engineer this is 4–6 weeks of focused work. For a junior team it's 12+ weeks and you'll miss things. The rule we use: if your bench has a senior engineer who has previously shipped auth in production, build. If not, buy.

The architecture we keep using when we build 

client → API Gateway → auth-service
                          ↓
                  ┌───────┼─────────┐
                  ↓                  ↓
             OTP provider     PostgreSQL (users, sessions, audit_log)
                  ↓                  ↓
            Redis (rate limit + OTP TTL)
Enter fullscreen mode Exit fullscreen mode
  • Stateless JWT access tokens (15-min TTL)
  • Stateful refresh tokens (90-day TTL, stored hashed in PostgreSQL with a one-time rotation rule)
  • Per-phone OTP rate limit (max 5/hour, exponential backoff thereafter)
  • Breach-list check on every password set/change (haveibeenpwned k-anonymity)
  • Argon2id for password hashing with reasonable cost parameters
  • Audit log entry for every auth event (login, logout, password change, MFA enroll, etc.)

Common mistakes

  • Storing OTPs in plaintext. Hash them like passwords with a short TTL.
  • Generating tokens without rotation. A leaked refresh token should self-revoke when used twice.
  • Forgetting to invalidate sessions on password change. Otherwise an attacker who held a session continues to hold it.
  • Using v4 UUIDs as session IDs. They're not random enough for some threat models. Use 128 bits of crypto-random base64.
  • Letting phone numbers be the only identifier. Phone numbers get recycled in India. Bind sessions to a stable user_id, not the phone.

Building auth (or any other piece of D2C infrastructure)?

When the unit economics force you to build vs buy your auth, Xenotix Labs has shipped both kinds. We've integrated Auth0, Clerk, Supabase Auth, and built custom phone-OTP systems for Indian-volume apps. Reach out at https://xenotixlabs.com.

Top comments (0)