Hecha con IA

Tu app hecha con IA funciona en la demo. Nosotros hacemos que aguante clientes reales.

Un login que falla, una base de datos cada vez más lenta, pagos que no desbloquean el acceso, una app que funciona en la preview y se rompe en directo. Un equipo sénior liderado por un CTO lee lo que hicieron Claude Code, Cursor, Lovable o Bolt, conserva lo que funciona y la lleva a producción en tu repo y tu nube.

¿TE SUENA?

En la demo funcionaba. Luego llegaron los usuarios de verdad.

Cada síntoma tiene una causa habitual, y casi ninguno obliga a empezar de cero. El problema rara vez es el producto: es la capa que una demo nunca enseña.

  • El login falla o echa a los usuarios

    Casi siempre, la autenticación sigue con la configuración por defecto de la herramienta: URL de redirección, caducidad de la sesión y confirmación por correo pensadas para una demo.

  • La base de datos va más lenta cada semana

    Consultas sin índices, pantallas que cargan tablas enteras y nadie mirando qué consulta es la lenta.

  • El pago entra, pero el acceso no se desbloquea

    Webhooks sin verificar, sin reintentos ni idempotencia: si un evento se pierde o llega dos veces, la cuenta queda en el estado equivocado.

  • Funciona en la preview y se rompe en directo

    Variables de entorno, secretos y ajustes de build que solo existen en la plataforma donde se construyó, sin un entorno de pruebas en medio.

  • No pasará la revisión de seguridad de un cliente

    Claves que viajan en el bundle del navegador, reglas de datos que nadie ha probado y ningún registro de accesos. El cuestionario pregunta justo por eso.

  • No puedes dar de alta a un segundo cliente

    Los datos no están separados por cliente, así que cada cuenta nueva comparte tablas y reglas con la primera.

  • Nadie se atreve a desplegar

    Sin tests en los caminos que mueven dinero o datos personales, sin CI, y cada arreglo de la IA rompe otra cosa.

  • La factura de la nube no para de subir

    Llamadas al modelo sin límite de gasto, funciones que se ejecutan en cada visita y recursos que nadie apagó.

Hecha con:Claude CodeCursorLovableBoltv0ReplitSupabase
Ingenieros trabajando en sus mesas con código en los monitores

EL VEREDICTO

Antes de reescribir nada, un veredicto por escrito sobre lo que tienes

El primer paso es el Diagnóstico y Blueprint: dos semanas en las que un CTO en activo lee tu repo con acceso de solo lectura y deja por escrito qué aguanta, qué no y qué hacer después.

  1. 01.

    Un veredicto por módulo

    Rescatar, rehacer o descartar, módulo a módulo: login, datos, pagos, integraciones, la capa de IA. Lo que funciona se queda.

  2. 02.

    Un registro de problemas por gravedad

    Qué bloquea el lanzamiento, qué es un riesgo y qué es cosmético, cada cosa con su causa y su arreglo.

  3. 03.

    La arquitectura objetivo

    Dónde vive cada pieza cuando lleguen los usuarios reales, en Node/TypeScript o Python, en tu propia cuenta de nube.

  4. 04.

    Un plan escrito y un presupuesto para la siguiente fase

    Alcance, orden y precio cerrado de la construcción, para que decidas con los números delante.

  5. 05.

    Ficheros de contexto para tus agentes de IA

    CLAUDE.md y AGENTS.md, para que Claude Code o Cursor sigan construyendo dentro del plan y no a su alrededor.

El documento es tuyo, construya quien construya la siguiente fase, y su precio se descuenta del MVP si lo construyes con nosotros.

CÓMO VA

De una demo que funciona a producción, paso a paso

Cada paso se puede rechazar sin perder el anterior. Solo te comprometes con la siguiente fase cuando ya has leído el plan.

  1. 01.

    Diagnosticar: el Diagnóstico y Blueprint

    Leemos la app y escribimos el veredicto, el registro de problemas, la arquitectura y el plan.

    2 semanas · se descuenta del MVP
  2. 02.

    Construir: blindar o rehacer

    Primero lo que bloquea el lanzamiento, después los módulos que marcó el veredicto. Cuando hay que rehacer el núcleo, es un MVP.

    MVP en 6 semanas · precio cerrado tras el diagnóstico
  3. 03.

    Operar: el equipo que la mantiene

    Ingenieros sénior que la mantienen en producción, siguen construyendo y revisan lo que escriben tus agentes de IA antes de que salga.

    mensual · tu código y tu nube, siempre

QUIÉN LEE TU APP

La lee primero un CTO que todavía escribe código

Marc Molas, fundador y CTO de Conectia PRO

Marc Molas

Fundador y CTO, Conectia PRO

Casi todas las apps hechas con IA que nos llegan tienen un buen producto y una capa que falta: autenticación, reglas de datos, webhooks, copias de seguridad, límites de gasto. Marc lee esa capa en persona antes de presupuestar nada, y el equipo la arregla primero, en tu repo, antes de añadir una sola funcionalidad.

3%de los ingenieros pasan la evaluación de CTOs en activo
14países en nuestra red de ingeniería sénior
72hdesde el plan firmado hasta tener ingenieros sénior en tu repo

PREGUNTAS

Lo que nos preguntan los fundadores antes de enseñarnos su app

¿Vais a reescribir mi app desde cero?

Solo lo que lo merezca. El veredicto va módulo a módulo, y en la mayoría de apps hechas con IA las pantallas y buena parte del modelo de datos se quedan. Lo que suele rehacerse es lo que no aguanta usuarios reales, como la autenticación, las reglas de datos o los pagos, y lo ves por escrito antes de gastar en ello.

¿Puedo seguir construyendo con Lovable, Cursor o Claude Code?

Sí. Dejamos ficheros de contexto (CLAUDE.md, AGENTS.md), tests en los caminos que importan y un CI que detecta lo que rompe un agente, así mantienes la velocidad con red de seguridad. Si la plataforma empieza a limitarte, el Blueprint dice cuándo y cómo salir de ella, pieza a pieza.

¿De quién es el código?

Tuyo, desde el primer commit. Trabajamos en tu repositorio y tu cuenta de nube, con un NDA mutuo y acceso de solo lectura durante el diagnóstico. El Blueprint es tuyo aunque la siguiente fase la construya otro.

¿Con qué stacks trabajáis?

Node.js y TypeScript (React, Next.js), Python (Django, FastAPI), PostgreSQL y Supabase, las nubes principales y la capa de IA: APIs de modelos, inferencia privada, evals y control de costes. Si una parte de tu app está en algo que no mantendríamos bien, el diagnóstico lo dice.

¿Cuánto se tarda?

El Diagnóstico y Blueprint dura dos semanas. Arreglar lo que bloquea el lanzamiento suele caber en las primeras semanas de la construcción, y un núcleo rehecho o un producto nuevo es un MVP en 6 semanas. El plan te da las fechas de tu caso.

¿Qué necesitáis de mí para empezar?

Acceso de solo lectura al repositorio y a los paneles del hosting, un NDA mutuo y una hora con quien mejor conozca el producto. Nunca pedimos contraseñas ni secretos por chat.

HABLA CON UN CTO

Cuéntale a un CTO qué construiste y qué se rompe

Envía el enlace, con qué la hiciste y qué está fallando. Un CTO lo lee y te responde en un día laborable: si el Diagnóstico y Blueprint encaja en tu caso y qué cubriría.

Primero, una respuesta por escrito; la llamada, cuando tú quieras.

Tu app ya demostró la idea. Ahora, que aguante.

Dos semanas para tener un veredicto por escrito sobre lo que tienes y un plan para llevarlo a producción.