Crear un clon de WhatsApp con InsForge

Vamos al grano. Este post no va de clonar WhatsApp pixel por pixel ni de hacer la demo perfecta para LinkedIn. Va de ver como curraria hoy un programador que sabe delegar bien en agentes, usando InsForge como backend y dejando que la IA se encargue de la parte pesada sin perder del todo el control.

El resultado final se parece mas a un Discord minimalista con estetica de WhatsApp que a un clon puro. Y sinceramente, mejor asi. Para un MVP tiene mucho mas sentido: login, salas publicas, mensajes en tiempo real y despliegue rapido. Si quieres trastear el codigo, el repo abierto es este: github.com/edunavajas/whatsapp-clone.

La idea no era copiar WhatsApp, era demostrar un flujo real

El punto del video no era presumir de interfaz, sino enseñar hasta donde puedes llegar hoy si montas bien el entorno. La jugada fue arrancar desde cero, crear el repo, conectar el backend y dejar que el agente hiciera primero la parte de definicion y luego la implementacion.

El repositorio se crea publico en GitHub y se baja en local con lo tipico:

git clone https://github.com/edunavajas/whatsapp-clone.git

En el video tambien se usa este comando para comprobar que la instalacion de la skill ha dejado su huella en el proyecto:

ls -la

Aqui entra una de las primeras decisiones inteligentes del flujo. Antes de ponerse a picar codigo como un loco, se instala una skill tipo “Grill with Docs” para que el agente haga preguntas y aterrice el alcance. Esto es justo lo contrario del vibe coding sin frenos. Primero se define que demonios quieres construir y luego ya te pones con ello.

Y aqui viene la parte que mas echo en falta en muchos contenidos de este estilo: que haces despues de clonar para no quedarte mirando la carpeta como un pasmarote. El camino razonable seria este. Primero instalas dependencias y arrancas la app en local para comprobar que el frontend respira antes de meter backend, autenticacion o realtime. Si eso ya falla, no tiene sentido ponerse a perseguir fantasmas en la parte de datos.

En el propio flujo se menciona npm install, pero luego se trabaja con pnpm, asi que lo coherente es quedarte con una sola herramienta y seguir hasta el final con ella:

pnpm install
pnpm run dev

Con eso deberias poder abrir la web en local y validar lo basico: que carga sin petar, que las pantallas principales existen y que no estas delante de un proyecto medio roto desde el minuto uno. No hace falta ponerse dramatico; basta con comprobar que el entorno arranca, que el login tiene sentido visual y que la estructura del clon ya esta ahi.

Luego si, en paralelo se levanta el proyecto en InsForge, se elige region en Europa por latencia y se autentica la CLI para que el editor pueda hablar con la instancia sin tener que andar copiando configuraciones raras a mano. El detalle importante aqui es que el propio flujo deja preparado un project.json con los datos de conexion y que eso se queda fuera del commit gracias al .gitignore. Eso esta bien pensado, para que engañarnos.

La secuencia buena seria: clonar, instalar, levantar local, conectar backend y solo entonces pedirle al agente que empiece a tocar tablas, politicas y realtime. Si te saltas ese orden, luego pasa lo de siempre: no sabes si el fallo es del frontend, del entorno, de la auth o de que el agente ha interpretado regular el alcance.

El MVP bueno no es el que mas cosas mete, es el que menos estorba

Una vez el agente empieza a preguntar, el proyecto deja de ser “hazme un WhatsApp” y pasa a ser algo bastante mas razonable. Se define como una web, no como una app movil. Se permite multiusuario, pero sin numeros de telefono. Las salas son publicas para cualquier usuario autenticado. Los mensajes son solo de texto. No hay edicion, no hay borrado y no hay archivos en el MVP. Al entrar existe una sala general y, ademas, cada usuario puede crear como mucho una sala propia.

La verdad, aqui esta una de las lecciones mas utiles del video: si no acotas, el agente se dispersa. Y cuando se dispersa, te genera mas codigo, mas contexto y mas basura. Por eso el autor separa la conversacion de definicion de la de implementacion, guarda el contexto en memoria y cambia incluso de modelo para la fase de picar codigo. No es postureo. Es gestion de contexto. Si llenas la ventana con demasiada historia, el modelo empieza a flojear y luego la gente le echa la culpa a la IA cuando el problema es que le has metido una empanada monumental.

Donde InsForge cambia de verdad la pelicula

Aqui esta la gracia de todo esto. InsForge no es solo una base de datos bonita. Es el backend completo que el agente puede operar desde el editor: autenticacion, realtime, reglas de seguridad, tablas, politicas y despliegue. Si vienes de Supabase, la idea te va a sonar rapido, pero con una diferencia importante: el flujo esta mucho mas pensado para currar con agentes.

El post anterior que publique sobre InsForge ya iba por ahi, pero en este ejemplo se ve de forma mas cruda. El agente detecta que necesita backend, crea las tablas de mensajes y salas, mete triggers, configura politicas y deja preparado el realtime para que el chat funcione sin tener que montar a mano la infraestructura de siempre.

Y eso importa porque el MVP deja de ser un amontonamiento de frontend con mocks. Aqui hay login real, datos reales y sincronizacion en tiempo real entre dos usuarios distintos. De hecho, esa es la prueba clave del video: abrir dos cuentas distintas en dos pestañas, escribir en una y ver el mensaje aparecer en la otra al instante.

Si clonas el repo para repetir la jugada, esa es tambien la validacion que yo haria al terminar la configuracion: primero comprobar que puedes iniciar sesion, luego entrar en una sala, despues escribir un mensaje y, por ultimo, abrir otra sesion distinta para verificar que el realtime no es postureo sino que de verdad esta funcionando. Si una de esas cuatro piezas falla, todavia no tienes el MVP cerrado aunque la interfaz se vea bonita en la captura.

Si quieres probar el mismo enfoque sin montarte tu propio backend a pelo, te dejo otra vez el enlace de InsForge con UTM, porque es justo la pieza que hace que este flujo tenga sentido.

Lo mejor del video es que tambien enseña las cagadas

Y menos mal. Porque si no, pareceria el tipico tutorial tramposo donde todo sale a la primera y luego en casa no le funciona a nadie.

La primera iteracion no queda bien. El diseño no sigue del todo la referencia cargada desde design.md, el login por email falla y el frontend no transmite esa sensacion de clon de WhatsApp que se buscaba. Luego viene otra iteracion, se corrige el login con Google y se vuelve a apretar al agente para que respete el diseño.

Despues aparece otro fallo bastante mas serio: los mensajes no se muestran bien y el flujo de chat no termina de cerrar. En ese punto se le pide al agente que valide con Playwright y que siga afinando. Esto es importante porque deja una leccion muy clara: desarrollo agéntico no significa desarrollo a ciegas. Tu sigues teniendo que mirar, probar, romper y volver a pedir cambios. Jarvis ayuda; Tony Stark sigue teniendo que saber lo que esta construyendo.

Al final, despues de varias fases, la cosa queda bastante decente. La interfaz ya recuerda mas a WhatsApp, el login entra bien, hay dos cuentas funcionando a la vez y los mensajes viajan en tiempo real. Incluso se pueden crear salas nuevas, aunque en el propio video se reconoce una limitacion: el listado de salas no refresca siempre fino y a veces toca actualizar para verlo bien. Ese tipo de detalle editorial habia que mantenerlo porque es justo lo que hace creible el articulo.

Si lo clonas hoy, este seria el recorrido sensato

No hace falta convertir esto en un tutorial de parvulario, pero si conviene dejar claro el orden mental del trabajo.

Clonas el repo y revisas que estas en el proyecto correcto:

git clone https://github.com/edunavajas/whatsapp-clone.git
ls -la

Instalas dependencias con un solo gestor y levantas local:

pnpm install
pnpm run dev

Con la app abierta, valida tres cosas antes de seguir. Una: que el frontend arranca sin errores gordos. Dos: que el flujo de login tiene sentido y no parece medio desconectado del resto. Tres: que la UI base del chat esta ahi y no es solo una portada bonita.

Despues toca backend. Si vas a seguir el video, aqui ya entra InsForge: crear proyecto, autenticar la CLI, dejar lista la conexion local y permitir que el agente monte auth, tablas, politicas y realtime. En este punto no estas “configurando por configurar”. Lo que buscas es que el proyecto deje de apoyarse en humo y pueda trabajar con usuarios y mensajes de verdad.

La ultima comprobacion ya es la buena: dos sesiones distintas, dos usuarios distintos y un mensaje cruzando de una a otra en tiempo real. Si eso funciona, ya tienes la demo viva. Si ademas puedes crear una sala y volver a entrar sin romper nada, mejor todavia.

Los comandos que aparecen en el flujo

Como en el video se mencionan comandos concretos, te los dejo aqui bien formateados. Algunos son del proyecto y otros del flujo de prueba local.

Para clonar el repo:

git clone https://github.com/edunavajas/whatsapp-clone.git

Para comprobar los archivos generados por la instalacion de skills:

ls -la

Para instalar dependencias, el agente propone npm install, aunque en el video se cambia a pnpm por preferencia personal:

npm install

Y esta es la variante que finalmente se usa para trabajar en local:

pnpm install
pnpm run dev

Hay un punto donde se menciona la instalacion de una skill de diseño con un comando mostrado en pantalla, pero el transcript literal no conserva la cadena completa. No la he inventado a lo loco porque eso seria humo. Si quieres reproducir ese paso exacto, lo sensato es tirar del video y del enlace que se menciona alli.

Lo importante de verdad no es ese comando suelto, sino el orden del conjunto: dependencias, servidor local, backend conectado y validacion con dos usuarios. Eso es lo que separa una demo bonita de un MVP que al menos se sostiene de pie.

Lo que me parece realmente util de este enfoque

Para que engañarnos: lo interesante no es el clon de WhatsApp. Lo interesante es el patrón. Defines el MVP, conectas el backend, dejas que el agente proponga y ejecute, revisas lo que ha hecho, corriges las partes flojas y despliegas cuando el resultado ya pasa un minimo filtro humano.

Eso reduce muchisima friccion. Y en un producto pequeño o en una prueba de concepto se nota una barbaridad. Mas todavia cuando el backend ya te resuelve autenticacion, reglas de seguridad y realtime. El video insiste mucho en esto y con razon: si la seguridad de tablas, login y acceso ya la gestiona InsForge, te quitas de encima una parte bastante delicada del MVP.

Ojo, eso no significa que ahora puedas apagar el cerebro. Para un producto serio, con usuarios de verdad, arquitectura mas compleja o requisitos finos de negocio, hay que pensar mas, revisar mas y diseñar bastante mejor. El propio video lo deja clarisimo. Esto es una demostracion de flujo, no una invitacion a delegarlo TODO y luego rezar.

Repo, deploy y conclusion honesta

El clon terminado se despliega desde el propio ecosistema de InsForge, con dominio generado por la plataforma y sin tener que montar otra pelicula aparte. Esa parte tambien es potente porque cierra el circulo: definicion, implementacion, backend y despliegue desde un flujo bastante compacto.

Si quieres ver el codigo con calma, te dejo otra vez el repo: github.com/edunavajas/whatsapp-clone. Y si quieres probar la herramienta que hace posible casi todo el backend del ejemplo, aqui tienes de nuevo InsForge.

En definitiva, el mensaje del video no es “mirad, la IA programa sola”. El mensaje correcto es otro: si sabes limitar el alcance, separar contexto, revisar iteraciones y apoyarte en un backend pensado para agentes, puedes sacar un MVP funcional ridiculamente rapido. Y eso, chaval, cambia bastante las reglas del juego.

Si quieres, despues de leer este post te recomiendo ver tambien el video anterior sobre InsForge y comparar ambos enfoques: uno mas conceptual y este mucho mas de trinchera. Ahi es donde de verdad se entiende por que este tipo de tooling esta empezando a marcar diferencias.

¿Qué te ha parecido?

Déjame tu opinión, pregunta o sugerencia. Los comentarios se sincronizan con GitHub Discussions .