«Funciona» y «está listo para clientes» son dos estados distintos, y entre uno y otro hay más trabajo del que parece. Una aplicación construida con Lovable, Bolt, Replit o Cursor puede estar perfectamente terminada desde el punto de vista de lo que hace, y no estar en condiciones de que alguien te pague por usarla.
La diferencia no es sofisticación técnica. Es qué pasa cuando algo va mal: cuando un usuario mete datos raros, cuando la base de datos se cae, cuando alguien pide que borres sus datos, cuando llegan cien personas a la vez, cuando el que la construyó no está disponible.
Siete áreas. De cada una, el mínimo para abrir a clientes de pago y la señal de que estás por debajo. Si tres o más están por debajo del mínimo, la aplicación todavía no está lista, y probablemente el trabajo pendiente sea de días, no de meses.
Esta guía la firma Miguel Quílez, director de Hiberus Booster, la unidad del grupo Hiberus especializada en inteligencia artificial. Hiberus es la primera consultora tecnológica española de capital privado, con más de 4.000 profesionales.
1. Seguridad y control de acceso
Mínimo para abrir: ningún usuario puede ver ni modificar datos de otro, probado con dos cuentas reales; ninguna clave de servicio ni de proveedor de pago por uso viaja al navegador; toda comprobación de permisos ocurre en el servidor, no escondiendo botones.
Estás por debajo si: no has probado el aislamiento con dos cuentas, o no sabes decir qué claves están en el navegador y cuáles en el servidor.
Es el área que más se subestima y la única cuyo fallo es irreversible: una fuga de datos no se deshace. El detalle de qué se comprueba está en la lista de los diez errores más frecuentes.
2. Datos: dónde viven y cómo vuelven
Mínimo para abrir: sabes en qué región se alojan los datos; existe copia de seguridad automática y la has restaurado al menos una vez, cronometrada; sabes cuántas horas de datos perderías en el peor caso.
Estás por debajo si: confías en que la plataforma hace copias pero nunca has probado la restauración. Una copia no verificada es una suposición, y se descubre el día que hace falta.
3. Operación: enterarte antes que el cliente
Mínimo para abrir: recibes un aviso automático cuando una petición falla; puedes consultar qué pasó hace tres días sin adivinarlo; alguien mira ese canal de avisos.
Estás por debajo si: tu sistema de detección de incidencias es que un cliente te escriba. Es el estado por defecto de casi toda aplicación generada con IA, porque los avisos no se configuran solos y nadie te los pide mientras construyes.
Un aviso a correo ante errores del servidor cuesta diez minutos. Registrar lo que pasa, algo más. Ninguno de los dos es opcional cuando hay dinero de por medio.
4. Legal: el RGPD no es un pie de página
Mínimo para abrir: política de privacidad que describe tu aplicación real, no una plantilla; base legal para cada dato que pides; capacidad de borrar los datos de una persona sin entrar a mano a buscar filas; contratos de encargado del tratamiento con los proveedores que tocan datos personales; datos alojados en la Unión Europea o transferencia documentada.
Estás por debajo si: la política de privacidad menciona servicios que no usas, o no sabrías atender una solicitud de borrado sin abrir la base de datos.
En España esta es el área que convierte un descuido técnico en una sanción, y la que más se deja para el final.
5. Soporte: qué pasa cuando escriben
Mínimo para abrir: un canal donde el cliente pueda escribir y una persona que lo lee; capacidad de responder «qué le pasó a este usuario concreto» sin reconstruirlo de memoria; un procedimiento para los tres problemas más probables (no puedo entrar, no me llegó el correo, se me ha cobrado mal).
Estás por debajo si: cada incidencia se resuelve improvisando y consultando la base de datos a mano.
No hace falta un sistema de tickets. Hace falta que el cliente tenga a quién escribir y que tú puedas saber qué le pasó.
6. Coste: el número que puede desbocarse
Mínimo para abrir: tope de gasto configurado en cada proveedor de pago por uso; límite de peticiones en los puntos de entrada que cuestan dinero; sabes cuánto te cuesta al mes un usuario activo.
Estás por debajo si: no tienes el coste por usuario. Sin ese número no puedes poner precio, y con modelos de IA por medio el margen se evapora sin que te enteres hasta la factura.
7. Evolución: quién la toca dentro de seis meses
Mínimo para abrir: el código está en un repositorio que controlas tú, no solo dentro de la plataforma; hay un documento de una página que explica cómo levantarla y qué depende de qué; puedes cambiar algo sin romper otra cosa sin darte cuenta.
Estás por debajo si: el único sitio donde existe la aplicación es la cuenta de la herramienta con la que la hiciste, o si cada cambio obliga a probar la aplicación entera a mano porque no hay ninguna comprobación automática.
Esta es la que no duele el primer mes y duele todos los siguientes. Es también la que decide si el día que quieras crecer puedes contratar a alguien o tienes que decidir entre parchear y reescribir.
Cómo se puntúa
| Áreas por debajo del mínimo | Lectura | Qué hacer |
|---|---|---|
| 0 | Lista para clientes de pago | Abre y revisa cada trimestre |
| 1 o 2 | Casi lista | Días de trabajo. Tápalo antes de abrir |
| 3 a 5 | No está lista | Semanas. Nada nuevo hasta cerrarlas |
| 6 o 7 | Es un prototipo, no un producto | Revisión completa antes de tocar nada |
Un matiz importante: no todas las áreas pesan igual en todos los casos. Si tu aplicación no guarda datos personales, el área legal casi desaparece. Si la usan tres personas de tu empresa, el soporte se resuelve por teléfono. Lo que no cambia nunca es la primera: el control de acceso a los datos es innegociable en el momento en que hay un usuario que no eres tú.
La pregunta que ordena todo lo demás
Antes de puntuar nada, respóndete a esto: si mañana la aplicación falla y no puedes arreglarla en 48 horas, ¿qué pierdes?
- Si la respuesta es «tiempo y algo de vergüenza»: abre ya, y arregla las áreas 1 y 2 en paralelo.
- Si la respuesta incluye clientes que se van o dinero que se devuelve: cierra las siete antes.
- Si la respuesta incluye datos de terceros expuestos o una sanción: revisión externa antes de abrir, sin excepción.
La mayoría de proyectos hechos con IA que llegan a nosotros están en el segundo caso, y casi siempre les faltan entre dos y cuatro áreas. Eso son días de trabajo, no un rehacer.
Preguntas frecuentes
¿Cómo sé si mi app hecha con IA está lista para clientes reales?
Revisando siete áreas: seguridad y control de acceso, datos y copias de seguridad, operación y avisos, cumplimiento legal, soporte, coste, y capacidad de evolución. De cada una hay un mínimo concreto. Si tres o más están por debajo, todavía no está lista; si son una o dos, suelen ser días de trabajo.
¿Cuál es la diferencia entre que funcione y que esté lista para producción?
Que funcione describe lo que hace cuando todo va bien. Estar lista describe qué pasa cuando algo va mal: un usuario mete datos raros, la base de datos se cae, alguien pide que borres sus datos, llegan cien personas a la vez o el que la construyó no está disponible. La segunda pregunta es la que cuesta dinero cuando no está respondida.
¿Qué área es la más importante de las siete?
El control de acceso a los datos, y no admite excepciones desde el momento en que hay un usuario que no eres tú: es la única cuyo fallo es irreversible, porque una fuga de datos no se deshace. Las demás pesan según el caso —si la aplicación no guarda datos personales, el área legal casi desaparece; si la usan tres personas de tu empresa, el soporte se resuelve por teléfono—.
¿Cómo compruebo mis copias de seguridad?
Restaurando una en un proyecto nuevo y cronometrándolo. Ese número es tu tiempo real de recuperación. Una copia automática que nunca se ha restaurado no es una copia, es una suposición, y se descubre el día que hace falta, que es el peor día posible.
¿Necesito monitorización para una app pequeña?
Necesitas enterarte antes que el cliente. Un aviso automático por correo cuando una petición devuelve error cuesta unos diez minutos de configuración y cambia por completo tu capacidad de reaccionar. Sin él, tu sistema de detección de incidencias son tus usuarios enfadados.
¿Qué me exige el RGPD antes de abrir a clientes en España?
Una política de privacidad que describa tu aplicación real y no una plantilla, base legal para cada dato que pides, poder borrar los datos de una persona sin entrar a mano en la base de datos, contratos de encargado del tratamiento con los proveedores que tocan datos personales, y datos alojados en la Unión Europea o la transferencia documentada.
¿Por qué importa saber el coste por usuario?
Porque sin ese número no puedes poner precio, y con modelos de IA de por medio el margen se evapora sin que te enteres hasta que llega la factura. Va acompañado de dos configuraciones que nadie trae puestas por defecto: tope de gasto en cada proveedor y límite de peticiones en los puntos de entrada que cuestan dinero.
¿Y si tengo varias áreas en rojo?
Depende de qué pierdes si la aplicación falla y no puedes arreglarla en 48 horas. Si solo pierdes tiempo, abre y arregla seguridad y datos en paralelo. Si pierdes clientes o tienes que devolver dinero, cierra las siete antes. Si hay datos de terceros expuestos o riesgo de sanción, revisión externa antes de abrir.
Si hay áreas en rojo, te decimos cuáles y en qué orden
Cuéntanos qué has construido y en qué punto estás. En 24 horas te decimos si está en condiciones de recibir clientes de pago o qué falta para que lo esté.
✓ ¡Recibido!
Gracias. Un especialista de Hiberus Booster te contacta en menos de 24 horas.
