> ## Documentation Index
> Fetch the complete documentation index at: https://supastack.dev/llms.txt
> Use this file to discover all available pages before exploring further.
> For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt

# Cómo crear un SaaS Web y Móvil con Next.js y Expo (Guía Monorepo)

Guía práctica de arquitectura SaaS multiplataforma: integre Next.js 16 y React Native Expo en un monorepo pnpm compartiendo Better Auth y Drizzle ORM.

_Publicado 2026-11-06._
_Actualizado el 2026-11-06._

> **¿Cómo compartir código entre Next.js y Expo en un monorepo?**
> Depende de la delimitación de módulos y la configuración de empaquetadores. La arquitectura más sólida utiliza pnpm y Turborepo para aislar modelos de base de datos, validaciones y contratos de API en paquetes internos sin interfaz. El servidor Next.js 16 ejecuta Drizzle ORM directamente contra PostgreSQL, mientras que la app Expo se comunica a través de puntos de enlace HTTP tipados y almacena los tokens de sesión en expo-secure-store. supastack proporciona esta configuración sin incompatibilidades entre Metro y Turbopack.

## El mayor obstáculo del SaaS multiplataforma: El conflicto de empaquetadores

Cualquier fundador sabe que una aplicación móvil multiplica la retención y el uso diario gracias a las notificaciones push y la presencia en la pantalla de inicio. Sin embargo, unir Next.js y React Native Expo en un mismo repositorio suele ser una fuente constante de errores.

Next.js utiliza Turbopack o Webpack orientados a entornos Node y Edge, mientras que Expo utiliza Metro para JavaScript móvil. Los intentos directos de compartir código fallan rápidamente: Metro intenta interpretar módulos propios de Node como `crypto`, mientras que Turbopack se bloquea con sintaxis JSX de React Native. La solución pasa por una encapsulación estricta en paquetes.


## Diseño de paquetes compartidos modulares: Autenticación, esquemas y contratos

En un monorepo profesional, las aplicaciones cliente (`apps/web` y `apps/mobile`) deben ser capas delgadas de interfaz. La lógica de negocio y las definiciones de datos se organizan en paquetes internos bajo `packages/`:

`@supastack/db`: Reúne las tablas de Drizzle ORM, relaciones y migraciones. Solo los entornos de servidor se conectan a la base de datos; los clientes solo importan los tipos TypeScript deducidos.

`@supastack/auth`: Configura Better Auth con dos puntos de entrada: rutas de servidor para el backend y un SDK cliente utilizado tanto por la Web como por la aplicación Móvil.

`@supastack/config`: Valida variables de entorno durante la compilación con Zod para evitar caídas en producción por configuraciones ausentes.

```
// packages/auth/src/client.ts
import { createAuthClient } from "better-auth/react";
import { expoClient } from "@better-auth/expo/client";

export function createCrossPlatformAuthClient(baseURL: string, storage?: any) {
  return createAuthClient({
    baseURL,
    plugins: storage ? [expoClient({ scheme: "myapp", storage })] : [],
  });
}
```


## Autenticación unificada: Cookies en la Web y SecureStore en Móvil

La Web y los dispositivos móviles requieren mecanismos de persistencia distintos. En navegadores, Next.js establece cookies HTTP-only con `SameSite=Lax`, garantizando protección CSRF y renderizado en servidor transparente.

En teléfonos móviles, las cookies son poco fiables dentro de las WebViews. La app de Expo extrae un token de sesión Bearer tras el flujo de OAuth o magic link y lo almacena en el llavero de iOS o Keystore de Android mediante `expo-secure-store`. Las peticiones móviles envían la cabecera `Authorization: Bearer <token>`, validada por el middleware de Better Auth.


## Pipeline de CI/CD y despliegue: Vercel, EAS Build y control de versiones

Mantener la Web y el Móvil en un mismo repositorio permite lanzamientos perfectamente coordinados. Cuando se aplica una migración en `@supastack/db`, el backend de Next.js se despliega en cuestión de segundos en Vercel o Cloud Run.

Al mismo tiempo, Expo Application Services (EAS Build) genera los binarios nativos para Apple TestFlight y Google Play. Al sincronizar las versiones de los paquetes compartidos en el monorepo, se eliminan los desajustes habituales entre proyectos independientes.