Antes de empezar: qué armaste exactamente
Lovable, v0, Cursor, Claude o Codex pueden generar cosas muy distintas: un frontend estático, una app de Node o Next.js, un backend en Python, o un frontend conectado a un servicio externo como Supabase.
Abrí el proyecto y anotá: lenguaje y framework (React con Vite, Next.js, Express, FastAPI, etc.), dónde viven los datos (SQLite, un archivo JSON, Supabase, Postgres, otra cosa), qué servicios externos usa (login, pagos, correo, APIs de IA), y qué comando la levanta (npm run dev no es lo mismo que un build de producción).
Con eso ya sabés qué tipo de hosting necesitás. Un sitio estático no necesita un servidor encendido todo el día. Una app con backend y base de datos sí.
1. Dominio propio y DNS
Una URL tipo mi-app.lovable.app sirve para probar. Para clientes conviene un dominio tuyo: transmite confianza y, sobre todo, no te ata a una plataforma.
- Registrá el dominio a tu nombre o al de tu empresa, no al de quien te ayudó.
- Apuntalo con registros A o CNAME según te indique el hosting.
- Tené en cuenta que los cambios de DNS pueden tardar en verse según el TTL configurado.
- Si ya usás ese dominio para correo, no toques los registros MX por error.
2. HTTPS sin excusas
Hoy los navegadores marcan como “no seguro” cualquier sitio sin HTTPS, y muchos servicios de login o pagos directamente no funcionan sin él. La buena noticia: el certificado puede ser gratuito (Let's Encrypt) y la mayoría de los hostings lo emiten solos.
Lo que sí tenés que confirmar es que la renovación sea automática. Los certificados vencen cada pocos meses, y un certificado vencido un viernes a la noche es de las caídas más evitables que hay.
3. Secretos fuera del código
Acá está el error más frecuente en apps generadas con IA. El chat necesita que funcione, entonces pega la clave donde sea.
- Las claves van en variables de entorno del servidor, no en el repositorio.
- Revisá que .env y .env.local estén en .gitignore.
- Ojo con los prefijos: en Vite, todo lo que empieza con VITE_ termina visible en el navegador. En Next.js pasa lo mismo con NEXT_PUBLIC_. Ahí no puede ir nada secreto.
- Si usás Supabase, la clave pública (anon) está pensada para el frontend solo si tenés activado Row Level Security con políticas bien definidas. La clave service_role nunca debe llegar al navegador.
- Si una clave se subió alguna vez a GitHub, rotala. Borrar el archivo no alcanza: queda en el historial.
4. Una base de datos que aguante usuarios reales
SQLite o un JSON “por ahora alcanza” mientras sos el único usuario. Con clientes reales aparecen los problemas: escrituras simultáneas, datos que se pierden al redeployar o plataformas serverless donde el disco no es persistente y el archivo desaparece.
- Pasá a una base administrada o a un Postgres/MySQL con usuario y contraseña propios.
- Separá la base de pruebas de la de producción.
- Si la app tiene login, revisá que cada usuario vea solo sus datos. Probalo con dos cuentas distintas, no lo des por hecho.
5. Backups que alguna vez probaste restaurar
Un backup que nunca restauraste es una expectativa, no un backup. Definí qué se copia (base de datos, archivos subidos por usuarios, configuración), cada cuánto y dónde. Que la copia esté fuera del mismo servidor.
Y probá restaurar antes de lanzar: si es lento o lleno de pasos manuales, mejor enterarte ahora.
6. Deploys que no rompan lo que ya funciona
“Cada cambio es pedirle otra vez al chat y rezar” no es un proceso. No hace falta nada complejo, pero sí algo repetible:
- El código en un repositorio (GitHub, GitLab), con cada versión identificable.
- Un entorno de prueba o una URL de preview antes de tocar producción.
- Una forma clara de volver a la versión anterior si algo sale mal.
- Cuidado con los cambios de base de datos: una migración mal hecha no se deshace con un rollback del código.
7. Login, pagos y callbacks apuntando a producción
Esto se olvida siempre. Los proveedores de login (Google, GitHub) y de pagos (Mercado Pago, Stripe) tienen URLs de retorno y webhooks configurados. Si siguen apuntando a localhost, el cliente paga y la app nunca se entera.
- Actualizá URLs de callback y webhooks al dominio real.
- Pasá de credenciales de prueba a credenciales de producción, y verificá que no queden mezcladas.
- Revisá CORS: permití tu dominio, no “cualquier origen”.
8. Monitoreo: enterarte antes que tus clientes
Si la app se cae un sábado, alguien tiene que saberlo.
- Un monitor de disponibilidad que te avise por mail o Telegram (hay opciones libres como Uptime Kuma).
- Logs de errores a los que puedas entrar sin pedirle nada a nadie.
- Una alerta si el disco o la base se están llenando.
- Si usás APIs de IA pagas, un límite de gasto configurado en el proveedor.
¿Querés que la publiquemos juntos?
Si ya tenés la app andando y querés que tus clientes la usen, escribime con el repositorio (o una descripción del stack) y qué necesita hacer. Revisamos qué falta, armamos el hosting a la medida de esa app y la dejamos con dominio, HTTPS, backups y una forma de actualizarla. Vos seguís iterando con el chat; nosotros nos ocupamos del servidor.