¿Cómo sé que mi prototipo está listo para producción?

Revise los 25 puntos de abajo. Si falta el control de acceso (punto 1), hay contraseñas en el código (2), las copias de seguridad no funcionan (6) o el repositorio no está a nombre de su empresa (22), corríjalo antes del lanzamiento, sea cual sea la puntuación.

¿Hay que reescribir una aplicación hecha con vibe coding?

Normalmente no. El resultado más habitual son unas cuantas correcciones de seguridad, un despliegue que funciona y después trabajo normal. Reescribir compensa cuando corregir llevaría más que una versión nueva. Solo se puede decir con honestidad después de ver el código.

¿Puedo hacer el checklist sin un desarrollador?

Sí. Donde no sepa responder, tiene una pregunta para quien escribió la aplicación. Un punto que falta no es motivo para reescribir, es una lista de trabajo.

¿Por qué está la monitorización en la lista?

Porque lo que funciona sin vigilancia algún día se para sin avisar. Una alerta debe comunicar la caída el mismo día, no un cliente ni una bajada en un gráfico semanas después.

Checklist antes del lanzamiento

Checklist de prototipo a producción: 25 puntos antes del lanzamiento

Un prototipo hecho con una herramienta de IA, por un freelance o heredado de una agencia está listo para usuarios reales cuando cumple 25 puntos en seis áreas: acceso, datos, despliegue, calidad, operación y propiedad. Los puntos 1, 2, 6 y 22 son obligatorios en cualquier caso. Márquelos abajo, se hace en una hora, incluso sin un desarrollador.

Descargarpdf

Lo que rellena y marca se queda solo en esta ventana del navegador. No guardamos ni enviamos nada. Al cerrar la página desaparece, así que imprima su resultado.

Para fundadores que tienen un prototipo y van a ponerlo delante de usuarios o clientes reales. Se hace en una hora, incluso sin un desarrollador. Donde no sepa responder, tiene una pregunta para quien escribió la aplicación.

Vibe coding le construye un prototipo. Nosotros, el software con el que funciona una empresa. Desde 2023 hemos entregado más de 15 proyectos en producción. Usamos esta lista en cada traspaso.

Un punto que falta no es motivo para reescribir. Es una lista de trabajo.

A. Acceso, permisos y secretos

1. Hay control de acceso en cada punto de entrada. También en la API, no solo en la pantalla principal. Compruébelo: entre como usuario normal e intente abrir el registro de otra persona desde su dirección.
2. Las contraseñas y claves no están en el código. Si alguna vez lo estuvieron, se han cambiado.
3. Solo un administrador ve las funciones de administración. No basta con un botón oculto.
4. El restablecimiento de contraseña y las invitaciones no se pueden abusar. El enlace caduca y solo funciona una vez.
5. Los formularios están protegidos contra bots y limitan el número de intentos.

B. Datos

6. Las copias de seguridad se hacen automáticamente. Y al menos una vez ha restaurado una de verdad.
7. Los cambios en la base de datos van por migraciones. No ediciones manuales en la base de datos en producción.
8. Los datos de prueba y los reales están separados. No se experimenta con los clientes.
9. Los datos personales están solo donde hacen falta. Sabe dónde están y quién tiene acceso.

C. Despliegue y entornos

10. Desplegar es un comando o un botón. No se hace a mano desde un ordenador concreto.
11. Hay un camino de vuelta. Puede volver a la versión anterior en minutos.
12. Tiene un entorno de pruebas separado de la operación real.
13. Otra persona puede poner en marcha la aplicación desde cero. Siguiendo las instrucciones, en un ordenador limpio.

D. Calidad

14. Los flujos principales tienen tests. Registro, pago, lo que el cliente paga.
15. Los tests fallan de verdad cuando algo se rompe. Un tick verde sin tests es decoración.
16. La CI bloquea el merge cuando fallan los tests. No solo avisa.
17. Las integraciones tienen una API y unos límites comprobados. Pasarela de pago, correo electrónico, servicios de terceros. Compruébelos antes de construir un plan sobre ellos.

E. Operación

18. Una alerta comunica la caída, no un cliente.
19. Los errores se registran y alguien los lee.
20. Las tareas en segundo plano están vigiladas. Lo que funciona solo algún día se para sin avisar.
21. Sabe cuánto cuesta la operación y qué pasa con el coste con 10 veces más usuarios.

F. Propiedad y cuentas

22. El repositorio está a nombre de su empresa, con todo su historial.
23. Las cuentas del dominio, la nube y los pagos están a nombre de la empresa. No en la cuenta personal de quien lo montó.
24. Más de una persona tiene acceso a las cuentas.
25. El contrato dice de quién es el código y qué recibe cuando deja al proveedor.

Por qué la monitorización está en la lista

Porque lo que funciona sin vigilancia algún día se para sin avisar. Nos pasó también a nosotros: en un proyecto para un cliente con un marketplace online, una tarea en segundo plano dejó de funcionar sin avisar y nadie se dio cuenta hasta que el tráfico cayó en un gráfico.

Faltaba una sola alerta que habría comunicado la caída ese mismo día. Por eso los puntos 18 a 20 son obligatorios, no un extra.

Puntuación

Cuente los puntos marcados. Pero mire primero los puntos 1, 2, 6 y 22. Si falta aunque sea uno, corríjalo antes del lanzamiento, sea cual sea la puntuación.

Estado	Veredicto	Qué significa
La base aguanta, los tests comprueban algo, el despliegue es repetible	Continuar	Siga construyendo funciones y complete los puntos que faltan sobre la marcha
La aplicación funciona, pero falta seguridad, tests o monitorización	Reforzar	Primero corregir eso, después funciones nuevas
Corregir llevaría más que una versión nueva	Empezar de nuevo	El prototipo queda como especificación, el código se reescribe

El resultado más habitual no es reescribir. Son unas cuantas correcciones de seguridad, un despliegue que funciona y después trabajo normal. Solo se puede decir con honestidad después de ver el código.

Incluso si se reescribe, el prototipo se queda. Muestra cómo debe funcionar el producto mejor que cualquier especificación.

Qué preparar antes de la conversación

acceso al repositorio o una exportación del proyecto desde la herramienta de IA,
quién usa hoy la aplicación y para qué,
esta lista, con los puntos de los que no estaba seguro marcados.

Preguntas frecuentes

¿Cómo sé que mi prototipo está listo para producción?: Revise los 25 puntos de abajo. Si falta el control de acceso (punto 1), hay contraseñas en el código (2), las copias de seguridad no funcionan (6) o el repositorio no está a nombre de su empresa (22), corríjalo antes del lanzamiento, sea cual sea la puntuación.
¿Hay que reescribir una aplicación hecha con vibe coding?: Normalmente no. El resultado más habitual son unas cuantas correcciones de seguridad, un despliegue que funciona y después trabajo normal. Reescribir compensa cuando corregir llevaría más que una versión nueva. Solo se puede decir con honestidad después de ver el código.
¿Puedo hacer el checklist sin un desarrollador?: Sí. Donde no sepa responder, tiene una pregunta para quien escribió la aplicación. Un punto que falta no es motivo para reescribir, es una lista de trabajo.
¿Por qué está la monitorización en la lista?: Porque lo que funciona sin vigilancia algún día se para sin avisar. Una alerta debe comunicar la caída el mismo día, no un cliente ni una bajada en un gráfico semanas después.

Siguiente paso

MVP y producto

Un producto funcional en semanas, no en meses

¿Quiere saber qué hacer con su prototipo?

Escríbanos qué puntos le faltan. Le respondemos en un plazo de dos días hábiles con algunas preguntas sobre su trabajo. Después acordamos qué hacemos primero.

Cuéntenos qué tiene que lanzar primero O una llamada introductoria de 15 minutos

Para quién

Servicios

Know-how

What is an AI agent? Plain answer, business examples

When is Excel no longer enough for a business?