VIBECODER: esto es lo ÚNICO que necesitas

Para montar una aplicación entera ya no hace falta un equipo. Realmente tampoco necesitas tener conocimiento técnico (para hacer un MVP).

Solamente sigue estos pasos. Al final de la guía te explico varias automatizaciones que deberías conocer.

Índice

1. Todo el stack

Antes de tocar nada, mira el mapa. Claude o ChatGPT escriben el código. GitHub lo guarda. Vercel muestra el frontend (lo que ve la gente) y Railway contiene tu servidor. Supabase te da la base de datos y el login (métodos de autenticación). Stripe cobra, Resend envía los correos, GoDaddy te vende el dominio (puedes usar otro proveedor), Cloudflare añade la capa de seguridad, y PostHog con GA4 te muestran todas las analíticas.

El error clásico del vibecoder es pasarse la semana comparando herramientas en vez de montar la aplicación. No lo hagas. Esto es lo que yo uso en todas mis aplicaciones. No pierdas más el tiempo y ponte a montar ya tu aplicación.

2. Crea el repositorio en GitHub

Lo primero que tienes que hacer es configurar el repositorio de código. Crea un repositorio privado, en Github, donde se almacenará tu código y las versiones de este (para tener un control de cada actualización)

Entra en github.com, crea la cuenta si no la tienes y dale a «New repository».

Nombre en minúsculas y con guiones, marca «Private» y añade el README.

3. Clónalo con GitHub Desktop

Clonar es bajarte el repositorio a una carpeta de tu ordenador que sigue conectada a GitHub. Para eso instala GitHub Desktop: es la forma de usar git sin aprenderte git, y para empezar es exactamente lo que quieres.

Inicia sesión, dale a «Clone a repository», elige el que acabas de crear y una carpeta donde vivirá. A partir de ahora el ciclo es siempre el mismo: cambias cosas, GitHub Desktop te enseña qué ha cambiado, escribes una línea diciendo qué hiciste y le das a «Commit» y a «Push». Cambios guardados y subidos, con dos clics.

De hecho esto de crear el commit (mensaje con los ficheros que se han modificado) y el push (subir al repositorio), lo puede hacer tu IA también si le das los permisos.

4. Claude o Codex (ChatGPT) escriben tu código

Esta es la parte que de verdad ha cambiado: el código lo escribe Claude Code, o Codex, que es el agente de programación de ChatGPT. El circuito es el mismo con los dos. Tú abres el proyecto, le cuentas qué quieres conseguir y él escribe los archivos. Tu trabajo ya no es teclear: es explicar bien, probar lo que te da y decidir si se queda.

Instalarlos es un momento y los dos van por el terminal. Antes necesitas Node: entra en nodejs.org, botón verde, siguiente, siguiente. Después son dos comandos por cabeza: uno instala y el otro arranca dentro de la carpeta del proyecto. Con Claude Code entras con tu cuenta de Claude; con Codex, con la de ChatGPT. Y si el terminal te da pereza, los dos tienen versión web: claude.ai/code y chatgpt.com/codex.

# Claude Code
npm install -g @anthropic-ai/claude-code
claude

# Codex (ChatGPT)
npm install -g @openai/codex
codex

Dos reglas que me ahorraron meses. Una: pídele el plan antes que el código; que te cuente qué va a tocar y por qué, y cuando el plan tenga sentido, que lo ejecute. Y dos: trocea. «Hazme la aplicación» sale mal; «hazme la pantalla de registro» sale bien. Después de cada trozo que funcione, commit, y a por el siguiente.

El stack de código, para que no haya dudas: yo siempre arranco con la última versión de Next.js para la aplicación y, cuando hace falta un server propio, con Fastify. Díselo a Claude en el primer mensaje y todo lo que escriba nace ya en el sitio correcto.

Para no empezar con la página en blanco, aquí debajo tienes el prompt que inicializa el proyecto con todo el stack de este artículo. Rellena los huecos de arriba, pégaselo tal cual y deja que pregunte lo que le falte.

Con esto la aplicación corre en tu ordenador, en localhost. El resto del artículo va de sacarla al mundo.

5. La carpeta rules: lo que el proyecto aprende

En la raíz de todos mis proyectos hay una carpeta rules/ con unos pocos Markdown, cortos, concretos y en el idioma del proyecto:

• architecture.md: qué carpetas hay y qué vive en cada una.
• components.md: cómo se escribe un componente en este proyecto.
• styles.md: la convención de estilos y de nombres de clase.
• conventions.md: los nombres, los imports y los commits.

El circuito tiene dos mitades. Antes de tocar código, Claude se lee rules/ entero: así lo nuevo sale con el estilo del proyecto y no con el suyo. Y antes de cerrar el día, apunta ahí lo aprendido: la decisión que se tomó, la trampa que se encontró y el porqué. Si una regla cambia, se corrige el archivo; no se apila una versión encima de otra.

La regla que lo sostiene es una: si te descubres explicándole lo mismo dos veces, eso va a rules/. Al mes, el proyecto tiene memoria de verdad, y cada sesión nueva empieza donde acabó la anterior en vez de empezar de cero.

Y para no escribirla a mano: en el botón de abajo tienes otro prompt para copiar y pegar que genera la carpeta rules/ entera mirando tu proyecto.

6. El frontend, a Vercel

Vercel es donde tu frontend deja de ser localhost. Entra con tu cuenta de GitHub, dale a «Add New Project», elige tu repositorio y a «Deploy». Dos minutos después tienes una URL pública del tipo tu-app.vercel.app con tu aplicación andando.

Y esta es la razón de todo el montaje del repositorio: cada push despliega solo. Tú le das a «Push» en GitHub Desktop y Vercel reconstruye y publica sin que hagas nada. Nada de servidores, nada de subir archivos por FTP como en 2009. El deploy deja de ser un evento y pasa a ser un hábito.

7. Supabase: el login y la base de datos

Casi toda aplicación necesita dos cosas aburridas de construir: que la gente pueda registrarse y un sitio donde guardar los datos. Supabase te da las dos hechas. Crea el proyecto, copia las dos claves que te da y pégalas en tu aplicación. Claude sabe exactamente dónde van.

El login con email o con Google son unas horas, no unas semanas. Y la base de datos es Postgres de verdad, no un juguete: lo que aprendas aquí te vale para siempre. La pieza que no puedes saltarte se llama Row Level Security: son las reglas que hacen que cada usuario vea solo lo suyo. Pídele a Claude que las escriba y, sobre todo, que te las explique antes de activarlas.

8. El backend, a Railway (si lo necesitas)

Un aviso: puede que no necesites esta pieza el primer día. Muchas aplicaciones viven perfectamente con el frontend en Vercel hablando directo con Supabase. El backend aparece cuando necesitas cosas que no pueden pasar en el navegador: tareas programadas, recibir webhooks de Stripe, procesos que tardan minutos.

¿Y por qué no montar el backend en Supabase, si ya lo tenemos para los datos? Porque Supabase no te deja tener un servidor corriendo: lo que ofrece son Edge Functions, funciones que se despiertan con cada petición, hacen su trabajo con un límite de tiempo y se apagan. Para un webhook suelto valen; para un server siempre encendido, con sus colas, sus WebSockets y sus trabajos de minutos, no.

Eso es justo lo que Railway sí te da: un proceso tuyo corriendo todo el día. Funciona igual que Vercel: conectas el repositorio, detecta qué es y lo despliega, y cada push lo actualiza. Mismo hábito, otra pieza. Y el server que va ahí, en mi caso, siempre es Fastify: ligero, rápido y Claude se lo sabe de memoria.

9. Stripe cobra por ti

¿Necesitas Stripe? Solo si tu aplicación cobra: una suscripción, un pago único, lo que sea. Una landing o una app gratis no necesitan esto.

Regla número uno de los pagos: tú nunca ves una tarjeta. El usuario paga en una página de Stripe (Checkout), y Stripe le avisa a tu aplicación con un webhook: «este usuario ha pagado esto». Tu base de datos apunta quién es premium. Eso es todo el sistema.

Los pasos básicos, en orden:

• Crea la cuenta en stripe.com. Arrancas en modo test, sin papeleo: la activación de verdad va al final.
• En el panel, crea tus productos con su precio: «Plan Pro, 9 €/mes» y listo.
• Copia las dos claves de test (la pública y la secreta) al .env de tu proyecto.
• Pídele a Claude el Checkout y el webhook: se los sabe con los ojos cerrados.
• Prueba el circuito entero con la tarjeta falsa 4242 4242 4242 4242: no mueve un euro.
• ¿Todo funciona? Activa la cuenta con los datos de tu negocio y tu banco, cambia a las claves reales y a cobrar.

10. Los correos, con Resend

Tu aplicación va a tener que mandar correos: la bienvenida, el enlace para recuperar la contraseña, el recibo. Y la tentación es mandarlos desde tu Gmail, que ya lo tienes. No lo hagas.

Gmail está pensado para personas, no para aplicaciones: tiene un tope de unos quinientos envíos al día, y un correo automático saliendo de una cuenta personal es exactamente lo que los filtros entienden por spam. A la que mandes unas decenas seguidas te marcan, y con la cuenta marcada hasta tus correos normales empiezan a caer en spam. Encima, el correo le llega al cliente desde tunombre@gmail.com en vez de desde tu-app.com, que suena a chiringuito.

Resend existe para esto: manda desde tu dominio, firma cada correo con SPF y DKIM (los sellos que Gmail y Outlook comprueban antes de fiarse de nadie) y te da una clave, una llamada y el registro de cada envío. Montarte tu propio servidor de correo, por cierto, es el hobby equivocado.

El paso que importa es verificar tu dominio: unos registros DNS que demuestran que ese correo sale de verdad de tu web. Los añadirás donde viva tu DNS: en GoDaddy tal cual, o en Cloudflare si haces el paso de dos más abajo. Con el dominio verificado tus correos llegan a la bandeja de entrada. Sin él, a spam. Es la diferencia entera entre que el enlace de recuperar contraseña llegue o no llegue.

11. El dominio, en GoDaddy

tu-app.vercel.app vale para enseñársela a un amigo; para el mundo quieres tu-app.com. Y no hace falta que sea GoDaddy: cualquier registrador te vale (Namecheap, Porkbun, el propio Cloudflare); yo uso GoDaddy y los pasos son los mismos en todos.

Busca el nombre, mira que el dominio que te guste y si está disponible, cómpralo: sale por unos 10-12 euros si no son palabras en concreto o un .ai/.rich, que suelen ser los dominios más caros.

Ahora la parte importante: el carrito. GoDaddy te va a ofrecer hosting, correo profesional, protección premium, un constructor de webs y tres cosas más. No, no, no, no y no. Todo lo que hace falta ya lo tienes en este stack, gratis y mejor. Compra el dominio pelado y sal de ahí.

12. Cloudflare, delante de todo (opcional)

El DNS es la guía telefónica de internet: cuando alguien escribe tu-app.com, el DNS dice a qué servidor ir. GoDaddy te lo gestiona por defecto, y con eso alcanza: apuntas los registros a Vercel y tu web ya está en producción con su SSL, porque el candado te lo pone Vercel solo, sin mover nada.

¿Entonces para qué Cloudflare? Es un proxy: si le pasas el dominio, tu tráfico cruza su red antes de llegar a Vercel, y ahí añade la capa extra: protección contra ataques y bots, caché y el mejor panel de DNS que hay. No es obligatorio; es el seguro que se agradece el día que salgas en portada o alguien te tome manía.

Si decides ponerlo, el traslado se hace una sola vez: creas la cuenta en Cloudflare, añades tu dominio y te da dos nameservers, que son dos direcciones. Vas a GoDaddy, las pegas donde dice «Nameservers», y desde ese momento el DNS se gobierna desde Cloudflare con el proxy delante. Y si no lo pones, tan tranquilo: GoDaddy apuntando a Vercel y a otra cosa.

13. PostHog y GA4: saber qué pasa

Sin analíticas estás pilotando a ciegas: no sabes si entra gente, ni de dónde, ni en qué pantalla se van. Se instalan los dos el primer día, cada uno es pegar un trocito de código que te da la propia herramienta o pedírselo a Claude, y responden a preguntas distintas.

GA4, que es la última versión de Google Analytics, responde de dónde viene la gente: Google, un tuit, una newsletter. PostHog responde qué hacen dentro: qué botones tocan, dónde se atascan, hasta grabaciones de sesiones para ver el ratón moverse. GA4 para decidir dónde promocionarte; PostHog para decidir qué arreglar. Los dos gratis de sobra para empezar.

Hazme caso. Tardas poco en añadir esto y realmente te da muchos datos para tomar mejores decisiones en el futuro.

14. Programar desde el móvil con Claude Dispatch

Esto era ciencia ficción hace dos años. Dispatch es Claude trabajando en la nube: le mandas un encargo desde la app del móvil, un «arregla el botón de pago, que en Safari no responde», y un agente se levanta en los servidores de Anthropic, lee tu repositorio de GitHub, hace el cambio, lo prueba y te deja el resultado listo para revisar. Tu ordenador puede estar apagado: todo pasa fuera.

Montarlo es corto: instala la app de Claude en el móvil, entra en la parte de Code y conecta tu cuenta de GitHub cuando te lo pida, eligiendo a qué repositorios puede entrar. Desde ese momento cualquier chat vale para encargar: describe el cambio como se lo describirías a una persona y revisa el resultado cuando te avise.

15. OpenClaw: tu agente en tu máquina

OpenClaw es la versión casera: un agente de código abierto que corre en tu ordenador y al que le hablas por WhatsApp o Telegram, como a un contacto más. La diferencia con Dispatch es dónde vive: aquí todo pasa en tu máquina, con tus claves y tus archivos, sin pasar por la nube de nadie.

Montarlo, paso a paso: abre el terminal y ejecuta los dos comandos de abajo; el segundo es un asistente que te lo pregunta todo. Cuando te lo ofrezca, conecta Telegram o WhatsApp escaneando un código, igual que WhatsApp Web. Y mándale un mensaje desde el móvil para comprobar que contesta. Diez minutos y sin tocar un archivo de configuración.

npm install -g openclaw@latest
openclaw onboard

Es básicamente como tener tu asistente virtual 24/7 disponible. De hecho va mejor que Claude Dispatch (en base a mi propia experiencia).

El aviso importante: OpenClaw vive en la máquina donde lo instalas, y esa máquina tiene que estar encendida 24/7. Si se apaga o se duerme, tu agente se apaga con ella y queda inservible hasta que la vuelvas a encender. Por eso la gente acaba poniéndolo en un Mac mini enchufado en un rincón o en un VPS, un servidor virtual que se alquila por pocos euros al mes.

16. Computer-use: que use el navegador por ti

Computer-use es Claude o Códex (ChatGPT) manejando tu navegador: ve la pantalla, mueve el ratón, hace clic y teclea. Y vale para cualquier faena de panel, no solo para una: los registros DNS en Cloudflare, dar de alta los productos y precios en Stripe o en PayPal, repasar un deploy en Vercel. Todo eso que es ir de pestaña en pestaña copiando valores, lo hace él mientras tú miras.

Dos reglas que SIEMPRE debes seguir. Nada sensible pasa por él: la sesión la inicias tú y ni contraseñas, ni tarjetas, ni claves; se encuentra el panel ya abierto. Y siempre con supervisión: tú ves cada clic en tu pantalla, y lo delicado, guardar, pagar, publicar, lo confirmas tú después de mirar lo que ha rellenado.

17. MCPs: el enchufe de tus herramientas

Un MCP es un conector estándar entre Claude y una herramienta: tu base de datos, tu repositorio, tu Stripe, tu Canva. En vez de copiar y pegar entre pestañas, Claude consulta y actúa directamente sobre la herramienta desde la conversación. Se conecta una vez y queda conectado.

El ejemplo que lo hace evidente es el de Canva: «hazme las tres imágenes del anuncio con la plantilla de siempre» y aparecen en tu cuenta, sin abrir Canva. Con el de GitHub revisa tus PRs, con el de Stripe te saca los pagos de esta semana, con el de Supabase consulta tus tablas. La regla para no montarte un parque de atracciones: conecta solo lo que uses cada semana. Dos o tres MCPs buenos valen más que quince puestos.

Resumen

• GitHub primero: el repositorio va antes que el código.
• GitHub Desktop: git sin aprenderte git.
• Claude escribe; tú pides el plan, pruebas y decides.
• La última versión de Next.js delante; Fastify en el server.
• rules/: se lee al empezar y se actualiza antes de cerrar el día.
• Vercel: publicar es hacer push.
• Supabase: login y Postgres hechos. RLS siempre.
• Railway: solo cuando algo no pueda vivir en el navegador.
• Stripe: la verdad es el webhook, y primero en modo test.
• Resend: dominio verificado o tus correos van a spam.
• GoDaddy vende el dominio; Cloudflare, opcional, pone el proxy.
• PostHog y GA4 desde el día uno: dentro y fuera.
• Dispatch desde el móvil: recados concretos, revisión en el ordenador.
• OpenClaw en casa: la máquina encendida 24/7 o no hay agente.
• Computer-use: cualquier panel, supervisado y sin datos sensibles.
• MCPs: conecta solo lo que uses cada semana.

Nada de esta lista es exótico ni caro: todo empieza gratis y todo está probado por miles de proyectos. La diferencia entre tener una idea y tener una aplicación con dominio, pagos y analíticas ya no es un equipo ni un año: es saber el orden de los enchufes. Ya lo sabes.

Móntalo este fin de semana

Mi consejo es que no lo leas dos veces: que lo montes. Sábado por la mañana: repositorio, clonado, y Claude escribiendo la primera pantalla. Sábado por la tarde: Vercel y Supabase. Domingo: dominio, Cloudflare, Stripe en modo test y las analíticas. El lunes tienes una aplicación en tu dominio, cobrando en pruebas y contando visitas.

Y antes de enseñársela a nadie, dos lecturas que van justo después de esta: las 9 skills de seguridad, para no ser la puerta por la que entran, y las 13 comprobaciones antes de subir a producción, para no estrenarte rompiéndola.

Y cuando la tengas, mándame el enlace por Instagram, que esas cosas me alegran el día.