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

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.