¿Su app de Lovable no funciona en producción? Cómo prepararla

¿Por qué mi app de Lovable funciona en la vista previa pero falla en producción?

En la vista previa usted es un único usuario, con datos de prueba, que hace clic en los recorridos que construyó. Producción añade desconocidos, dinero real y tiempo. Los fallos que siguen rara vez son una línea de código mal escrita. Son decisiones que faltan: quién puede leer qué fila, qué pasa cuando un pago se completa pero el navegador se cierra y quién se da cuenta cuando un correo deja de enviarse.

• Fugas de datos entre usuarios. Supabase permite que cualquier rol con permisos lea y escriba una tabla de un esquema expuesto salvo que la seguridad a nivel de fila esté activada y sus políticas sean correctas.
• Secretos en el navegador. La clave publicable (anon) se puede incluir sin problema; la clave service role se salta todas las políticas RLS y nunca debe llegar al navegador.
• Pagos que se descuadran. Un pago que vuelve a una página de éxito no demuestra que se haya pagado. El servidor tiene que confirmarlo con Stripe.
• Cambios que rompen funciones antiguas. Sin pruebas de regresión, cada nuevo prompt puede deshacer algo que funcionaba la semana pasada.
• Caídas silenciosas. Sin supervisión, sus clientes encuentran el error antes que usted.

Nada de esto es exclusivo de Lovable. Cualquier primera versión rápida, escrita por una persona o por IA, suele tener las mismas carencias, porque la función de un prototipo es demostrar la idea, no sobrevivir a desconocidos.

¿Está una app de Lovable lista para producción de serie?

En parte. La documentación de Lovable dice que escribe políticas de seguridad a nivel de fila para las tablas cuando conecta Supabase, que ejecuta un análisis de seguridad rápido al publicar (una revisión de la base de datos, como tablas sin RLS o reglas que dejan pasar a todo el mundo, una auditoría de dependencias y una comprobación del servidor MCP) y que ofrece un análisis más profundo que se inicia a mano. También dice, con claridad, que el análisis no puede garantizar una seguridad completa y no sustituye a una revisión de seguridad exhaustiva.

Es una descripción justa. Un análisis puede decirle que existe una política. No puede decirle si la política se ajusta a sus reglas de negocio, por ejemplo, que un administrador del equipo pueda ver las facturas pero un miembro no. Ese criterio es lo que significa en la práctica estar lista para producción.

¿Qué significa estar lista para producción en una app de Lovable?

¿Cómo añado pagos con Stripe a una app de Lovable de forma segura?

La integración de Stripe de Lovable funciona mediante edge functions, de modo que su clave secreta queda fuera de la app, y los pagos únicos abren Stripe Checkout. Según la documentación de Lovable, no configura webhooks por defecto: la app consulta el estado de pagos y suscripciones directamente a Stripe, y los webhooks se pueden añadir a petición. También indica que los ID de precio son distintos en modo de prueba y en modo real, así que para pasar a producción hacen falta nuevos.

Consultar el estado bajo demanda funciona para un pago sencillo. En cuanto vende suscripciones, normalmente querrá también webhooks, porque las renovaciones, las tarjetas rechazadas y las cancelaciones ocurren cuando su usuario no está en la página. La documentación de Stripe es concreta sobre cómo hacerlo de forma segura:

• Verifique cada webhook con la cabecera Stripe-Signature y el secreto de su endpoint, sobre el cuerpo original de la petición.
• Cuente con eventos duplicados y desordenados. Registre los ID de los eventos que ha procesado para que cada uno se procese una sola vez (idempotencia).
• Recuerde que Stripe reintenta durante hasta tres días los envíos fallidos en modo real, así que un endpoint roto puede recibir días de eventos de golpe cuando se recupere.
• Mantenga separados los secretos de prueba y los reales. Los objetos de un modo no son visibles en el otro.

¿Debo arreglarlo yo, contratar a un freelance o traer a un equipo?

Si su app tiene unos pocos usuarios, no cobra y no maneja datos sensibles, puede recorrer usted mismo la tabla anterior con el análisis de seguridad de Lovable y el Security Advisor de Supabase, que señala tablas con RLS desactivado y políticas que dejan pasar a todo el mundo. Es una buena forma de aprovechar una tarde.

Un freelance o un sprint de rescate a precio cerrado encaja con un problema conocido y acotado: una integración rota, una auditoría. Para eso suelen ser la opción más barata. Lo que un arreglo puntual no le da son los seis meses siguientes: las pruebas, las versiones, las actualizaciones y el incidente fuera de horario. Esa responsabilidad continua es lo que vendemos: Plutonapps está especializada en llevar apps de Lovable a producción y operarlas, y nuestra comparativa de agencias, freelancers, contratación interna y suscripciones explica cuándo encaja cada una.

¿Qué pasa tras el lanzamiento y quién está de guardia?

El lanzamiento es donde cambia el trabajo, no donde termina. Alguien tiene que vigilar los errores, aplicar las actualizaciones de seguridad, atender los incidentes y lanzar la siguiente función sin romper la anterior. Con nuestro plan Starter, los fundadores siguen escribiendo prompts en Lovable y nuestros ingenieros incorporan cada versión al producto real, ejecutan pruebas de regresión y de regresión visual, revisión de código y controles de seguridad en cada cambio, despliegan en producción dos veces por semana y atienden hasta cinco incidencias de emergencia en producción al mes, con soporte en horario laboral. Growth añade despliegue continuo y soporte 24/7. Los detalles y los precios están en nuestra página de precios.