No hubo lanzamiento. Montaste algo en Lovable o en Cursor un par de tardes para ver si la idea aguantaba. Se lo enseñaste a unas cuantas personas. Una empezó a usarlo de verdad. Luego unas cuantas más. En algún momento, dinero o datos o el flujo de trabajo real de alguien empezaron a depender de ello, y el prototipo desechable pasó a ser la cosa que ya no puedes desechar.
Nadie tomó esa decisión. Te pasó. Y ahora operas un sistema en producción que se diseñó para ser prescindible, que es un sitio genuinamente incómodo. El instinto es declararte en quiebra y reescribirlo “bien”. Ese instinto casi siempre es incorrecto, y quiero explicar por qué, y qué hacer en su lugar.
El prototipo no fue un error
Empecemos aquí, porque la vergüenza es parte de lo que empuja a la gente hacia la reescritura. Construir el producto como prototipo fue el movimiento correcto. No sabías si la idea funcionaba, así que gastaste lo mínimo posible en averiguarlo. Eso es buen criterio, no un atajo por el que debas sentirte mal.
El prototipo hizo su trabajo. Respondió a la pregunta “¿quiere esto alguien?”, y la respuesta volvió que sí. El problema no es que construyeras un prototipo. El problema es que el éxito del prototipo cambió en silencio lo que necesita ser, y nada en el código cambió para acompañarlo.
Un prototipo optimiza una sola cosa: aprender rápido. Un producto optimiza otra distinta: no romper a la gente que ahora depende de él. Mismo código, distinto trabajo. El ascenso es trabajo real precisamente porque esos dos trabajos tiran en direcciones opuestas.
Por qué la reescritura es una trampa
Cuando miras el código de un prototipo con ojos de producción, cada esquina recortada se ve, y el total parece un desastre que deberías reemplazar. Aquí está por qué reemplazarlo suele fallar.
La reescritura tira lo único que el prototipo de verdad contiene y tiene valor: una definición funcionando y validada de lo que hace el producto. Cada rareza de ese código es una decisión, hasta las accidentales. Algunas de esas rarezas son la razón de que a los usuarios les guste. Una reescritura desde cero pierde todo eso y te obliga a redescubrirlo rompiendo cosas delante de la gente que ahora depende de ti.
El prototipo es, lo pretendieras o no, la especificación más veraz que tienes. No se puede malinterpretar, porque arranca. Tirarlo para escribir una versión “de verdad” es cambiar una especificación demostrablemente correcta por un documento que todavía no demuestra nada. Ese trueque es peor de lo que parece el día en que lo haces.
Hay un conjunto estrecho de casos donde la reescritura es correcta, y van sobre la idea, no sobre el código: aprendiste que el producto debería ser fundamentalmente distinto de lo que prototipaste. Si la forma es la buena y solo los cimientos tiemblan, refuerzas los cimientos. No demueles la casa para arreglar el sótano. Esa distinción es todo el asunto de arreglar una app de vibe coding sin reescribirla.
Qué exige de verdad el ascenso
Ascender un prototipo no es un solo proyecto grande. Es una secuencia de mejoras concretas, cada una disparada por el hecho de que la app ahora tiene usuarios reales. Este es el orden que me ha funcionado.
Recupera lo que hace. Antes de cambiar nada, haz que el sistema se explique, feature a feature, incluidas las partes que ya no recuerdas haber escrito. Estás convirtiendo un prototipo que entiendes vagamente en un producto sobre el que puedes razonar. Es el antídoto al miedo a tocar tu propio código: no puedes ascender con seguridad lo que no sabes explicar.
Dibuja una línea alrededor de lo que sostiene peso. No todo en el prototipo importa igual. El flujo de registro, el camino del pago, los datos que sería catastrófico perder: eso ahora sostiene peso. El resto todavía puede ser cutre. Saber qué es qué es lo que te permite gastar esfuerzo donde cuenta en vez de pulir una pantalla de ajustes que nadie toca.
Pon una red de seguridad donde sostiene peso. Aquí es donde entran los tests y la estructura, y solo aquí. No pruebas el prototipo entero. Pones tests de caracterización alrededor de los caminos que dolerían a un usuario real si se rompieran, para que el siguiente cambio que haga un agente no pueda tumbarlos en silencio. La pregunta de cuándo añadir tests y arquitectura tiene una respuesta limpia durante el ascenso: en el momento exacto en que un camino pasa a sostener peso, y ni una feature antes.
Cierra los agujeros obvios. El prototipo casi con seguridad publica secretos en el código y confía en su entrada, porque eso es lo que hacen los prototipos. El ascenso es cuando los agujeros de seguridad que deja el vibe coding dejan de ser aceptables, porque un prototipo con una fuga de datos es un experimento y un producto con una fuga de datos es un incidente.
La deuda vence durante el ascenso
La razón de que esto agobie es que el ascenso es cuando llegan de golpe todas las facturas aplazadas. La comprensión que nunca construiste, los tests que nunca escribiste, la estructura que nadie diseñó: todo era gratis mientras la app era un experimento, y todo vence en el momento en que se convierte en algo de lo que la gente depende.
No es casualidad. Es la misma deuda del vibe coding, llegando a su vencimiento. El ascenso no creó la deuda. La reclamó. Lo que significa que el objetivo no es pagarla toda, sino pagar la parte que el nuevo estatus de producción de verdad exige, en el orden que mantiene a los usuarios a salvo, y dejar el resto cutre a propósito.
Y conviene decir con claridad que esto es una transición real, no una formalidad. Ascender un prototipo a producto significa que ahora tiene que instalar un comportamiento duradero en usuarios reales, no solo demostrar que una idea es plausible. Es un listón más alto, y el código tiene que crecer hasta él. El arco entero, de un montaje de fin de semana a algo que puedes operar, es el puente que intento trazar al ir del vibe coding a producción.
Dónde encaja PaellaDoc
La parte más dura de ascender un prototipo es que todo lo que necesitas para hacerlo bien falta: la intención detrás de cada feature, las decisiones que tomaste y olvidaste, la evidencia de que algo funciona. El prototipo tiene el comportamiento pero no el registro de él.
PaellaDoc está hecho para reconstruir ese registro a partir de lo que el prototipo ya es. Lee la app funcionando y la convierte en un modelo local de lo que hace, te da un sitio donde enganchar las decisiones y el contrato de aceptación que nunca escribiste, y guarda la evidencia según endureces cada camino. El prototipo se queda. Lo que añades es la memoria que nunca tuvo, para que el ascenso sea una serie de mejoras deliberadas en vez de una reescritura de la que te arrepientas.
Preguntas frecuentes
¿Debería reescribir mi prototipo antes de lanzarlo de verdad? Normalmente no. Una reescritura tira una definición del producto que funciona y está validada, y te obliga a redescubrirla rompiendo cosas para usuarios reales. Reescribe solo cuando has aprendido que el producto debería ser fundamentalmente distinto, no porque el código se vea desordenado.
¿Cómo sé qué partes del prototipo endurecer? Sigue a los usuarios. Los caminos que manejan sus datos, su dinero o su flujo de trabajo central sostienen peso y necesitan tests y endurecimiento. El resto puede seguir cutre hasta que se gane la atención.
¿Cuándo se convierte oficialmente un prototipo en producto? Cuando alguien depende de él de un modo que le dolería si se rompiera. Rara vez hay un momento de lanzamiento. La dependencia es lo que cambia los requisitos, lo anuncie alguien o no.