How much code can I really share between Next.js and React Native?

Typically the majority of the non-UI code: TypeScript types, validation schemas, the API client and business/domain logic. What you don't share is UI (DOM vs native primitives), navigation, and secure storage — those are platform-specific for good reasons and belong behind a shared interface.

Where do I store the auth token on web vs mobile?

On web, an httpOnly cookie so JavaScript can't read it; on mobile, the OS secure keychain/keystore. Never share one implementation across both — expose a small storage interface in shared code and implement it per platform.

What does Ali Asghar specialize in?

Senior full-stack (MERN) engineering and technical leadership — multi-tenant SaaS architecture, production payment systems, and AI-assisted delivery, primarily in React, Next.js, Node.js, NestJS, and PostgreSQL.

Is Ali available for hire or remote work?

Yes — open to select senior software engineering and technical-lead roles, remote-first from Lahore, Pakistan. The fastest way to reach him is WhatsApp or email, both linked in the contact section.

What is Ali's tech stack?

Frontend: React, Next.js, TypeScript, Tailwind. Backend: Node.js, NestJS, PostgreSQL, Redis, BullMQ. Cloud & DevOps: AWS, OVHcloud, Docker, GitHub Actions CI/CD. Plus Stripe, GA4/Measurement Protocol, and agentic AI tooling.

What kind of products has Ali built?

Production SaaS with real stakes: multi-tenant WPS-compliant payroll (Paylio), a payment-analytics dashboard over live PSP webhooks, multi-currency European commerce, and an automated print-on-demand render pipeline.

How does Ali work with clients and teams?

As a technical lead: he scopes the smallest valuable slice, owns the architecture and code review, leads a five-person team across a nine-product portfolio, and measures engineering in business outcomes — not just features shipped.

The CTO's dilemma: sharing code between a Next.js web app and a React Native mobile app

A founder needs web and mobile, and doesn't have two teams' worth of budget. The answer isn't 'write it twice' or 'use one framework for everything' — it's a monorepo that shares the logic and types across a Next.js web app and a React Native mobile app, while keeping the platform-specific parts separate. Here's how to structure it and where the line is.

What you can share (most of it)

The valuable, expensive-to-write code is platform-agnostic: TypeScript types, validation schemas, API client, business logic, and domain models. In a monorepo those live in shared packages that both the Next.js app and the React Native app import. You write the rules of your product once, and both platforms obey them.

// monorepo layout
// packages/core     -> types, validation (zod), domain logic (shared)
// packages/api      -> typed API client (shared)
// apps/web          -> Next.js (imports @acme/core, @acme/api)
// apps/mobile       -> React Native (imports @acme/core, @acme/api)
// apps/server       -> Node/Express BFF (imports @acme/core for shared types)

What you must NOT share: the platform edges

UI is platform-specific (React DOM vs React Native primitives) — sharing it is where 'write once, debug everywhere' pain comes from. And some things are dangerously different: token storage. On web, an auth token belongs in an httpOnly cookie; on mobile, it belongs in the secure keychain/keystore. Sharing that code would either weaken web security or break on mobile. Keep the storage adapter platform-specific behind a shared interface.

Share the logic, not the platform edges. Auth-token storage, navigation, and UI primitives differ by platform for good reasons — abstract them behind a shared interface, don't force one implementation.

A Backend-for-Frontend keeps both honest

A thin Node/Express BFF sits between both apps and your services, shaping responses for exactly what the clients need and holding shared server-side types. It means the mobile app isn't making five round-trips where the web app makes one, and both consume one consistent, typed contract.

The realistic share ratio

High share: types, validation, API client, business/domain logic, formatting.
Partial share: state management patterns and hooks (often shareable with care).
No share: UI components, navigation, and secure storage — platform-specific by design.

Key takeaways

A TypeScript monorepo lets web and mobile share the expensive logic and types.
Share business logic, validation and the API client; keep UI and storage platform-specific.
Store tokens in httpOnly cookies on web and the secure keychain on mobile — behind one interface.
A Node/Express BFF gives both clients one consistent, typed contract.