¿Cuándo conviene sustituir una herramienta sin código?

Un equipo debe sustituir una herramienta sin código cuando el coste de seguir atrapado supera el de poseer y operar la aplicación. Ese momento llega antes de que la plataforma sea inutilizable. Suele aparecer cuando los cambios habituales exigen soluciones provisionales, los datos no pueden salir limpiamente, las integraciones dependen de conexiones frágiles o un desarrollador no puede reproducir el sistema en funcionamiento a partir de una exportación.

La decisión no es código frente a no-code. Ese planteamiento convierte una cuestión práctica de propiedad en una discusión de identidad. La comparación útil está entre dos modelos operativos: alquilar comportamiento dentro de los límites de un proveedor o conservar código fuente que otro equipo pueda inspeccionar, ejecutar, modificar e implementar. Un creador de IA que exporta código fuente puede acortar el camino hacia el segundo modelo, pero solo si la exportación es real y el equipo está preparado para hacerse cargo de lo que recibe.

¿La herramienta limita las entregas o solo molesta al equipo?

Sustituye la herramienta cuando sus restricciones cambian repetidamente lo que el negocio puede entregar, no porque su editor tenga unas cuantas manías irritantes. Toda plataforma tiene fricción. La migración justifica su coste cuando el mismo tipo de solicitud sigue chocando con un límite que controla el proveedor.

Revisa el trabajo solicitado durante los últimos tres meses. Marca cada solicitud como entregada con normalidad, entregada con una solución provisional, aplazada o rechazada por la plataforma. Después registra las horas dedicadas a mantener esas soluciones. Esto aporta mejores pruebas que una sala llena de opiniones sobre si la herramienta parece flexible.

Un límite real de plataforma tiene una forma reconocible. Una regla de precios no puede expresar una excepción exigida por un contrato. Un flujo no puede pausar, bifurcarse y reanudarse con el estado que necesita la operación. Un trabajo programado solo se ejecuta en intervalos que impiden cumplir un plazo operativo. Una interfaz necesita una interacción que el sistema de componentes no puede producir. El equipo empieza a cambiar la política para que encaje con la aplicación, en lugar de cambiar la aplicación para que encaje con la política.

No cuentes cada solicitud personalizada como prueba. Algunas solicitudes son malas ideas, y el código fuente no las mejorará. Pregunta si un desarrollador competente con una pila convencional podría implementar la solicitud de forma segura y si el valor esperado para el negocio supera su coste de mantenimiento continuo. Si ambas respuestas son afirmativas y la plataforma sigue bloqueándola, la restricción debe figurar en el caso de migración.

Una sola función bloqueada rara vez justifica una sustitución. Un patrón sí. Uso un umbral sencillo: cuando dos ciclos de planificación consecutivos incluyen trabajo comprometido que la plataforma no puede entregar sin un proceso manual, un servicio externo de automatización o datos duplicados, programo una evaluación de salida. Esa evaluación puede seguir recomendando quedarse, pero esperar a una crisis elimina la opción de migrar con cuidado.

La exportación del código fuente debe superar una prueba de propiedad

Una exportación del código fuente solo importa cuando un desarrollador independiente puede compilarla y ejecutarla sin la plataforma original. Un archivo zip lleno de archivos generados no es automáticamente código fuente portable. Puede omitir definiciones de base de datos, documentación de secretos, trabajos en segundo plano, archivos de recursos, versiones de dependencias o la configuración de implementación que hace que producción se comporte de otra forma que un portátil.

Trata la exportación como una prueba de aceptación, no como una casilla en una página de funciones. Crea una máquina nueva o un contenedor limpio, entrega a un desarrollador la exportación y las variables de entorno por escrito, y prohíbele acceder al editor visual. El desarrollador debe poder instalar dependencias, crear una base de datos vacía, aplicar migraciones, iniciar la aplicación, ejecutar sus pruebas e implementarla en una cuenta controlada por el equipo.

Usa una lista de verificación con resultados observables:

1. El repositorio se instala con un comando documentado y versiones de dependencias bloqueadas.
2. El esquema y las migraciones de base de datos crean las mismas estructuras que se usan en producción.
3. La autenticación, el almacenamiento de archivos, el trabajo programado, el correo y los servicios externos tienen puntos de configuración explícitos.
4. Las pruebas cubren las reglas de negocio que sería costoso redescubrir.
5. Una implementación fuera del creador puede servir una prueba básica sin llamar a un entorno privado que solo proporciona el proveedor.

El quinto punto detecta la exportación que parece completa pero sigue atada. Las pantallas generadas en React son útiles, pero no demuestran propiedad si cada acción llama a un endpoint no documentado del proveedor. Lo mismo ocurre con un backend que solo se ejecuta a través de un host de funciones propietario. Una exportación limpia deja esas dependencias a la vista para que el equipo decida si conservarlas o sustituirlas.

Ejecuta esta pequeña inspección del repositorio después de cada exportación candidata:

find . -type f | sort
find . -type f \( -name '*.env*' -o -name '*migration*' -o -name '*schema*' \) | sort
grep -R "https://\|vendor-runtime\|TODO" .

El resultado esperado no es una lista mágica. Es un inventario que el equipo puede explicar. Llamadas de red desconocidas, migraciones ausentes, credenciales confirmadas y marcadores TODO en torno a la autenticación son fallos que hay que resolver antes de elegir el creador.

La portabilidad de datos es más que descargar filas

Los datos son portables cuando el equipo puede extraer registros de negocio, relaciones, archivos, historial y suficiente significado para reconstruir el sistema en otro lugar. Una exportación CSV de las filas actuales puede cumplir una promesa de marketing y, aun así, perder adjuntos, eventos de auditoría, definiciones de enumeraciones, registros eliminados lógicamente, marcas de tiempo y los identificadores que unen una tabla con otra.

Crea un inventario de datos antes de hablar de estimaciones de migración. Para cada entidad, registra su responsable, volumen aproximado, regla de retención, formato de exportación, identificador estable, relaciones, adjuntos de archivo y requisitos de historial. Después exporta una muestra e intenta cargarla en una base de datos de destino vacía. Inspeccionar sin importar demuestra muy poco.

La documentación de pg_dump de PostgreSQL distingue de forma útil entre scripts de texto plano y formatos de archivo que pg_restore puede restaurar selectivamente. La lección general se aplica incluso si la herramienta actual no usa PostgreSQL: una exportación debe conservar la estructura y permitir una restauración controlada, no limitarse a mostrar registros para lectura humana. Prefiero un conjunto sencillo de tablas y archivos documentados a una hoja de cálculo vistosa que haya borrado las claves foráneas.

Las obligaciones de privacidad hacen esta prueba más exigente. Identifica dónde viven las copias de seguridad, las exportaciones y los datos de la aplicación, quién puede acceder a ellos y cómo se propagan las solicitudes de eliminación. Mover la aplicación y dejar exportaciones antiguas en unidades personales en la nube crea un segundo problema de gobernanza de datos. Si la residencia importa, confirma que el entorno de destino y cada servicio de almacenamiento pueden conservar los datos pertinentes en el país exigido. Una vaga afirmación de hosting global no responde a esa pregunta.

Prueba la conciliación con recuentos y hashes. Para cada tabla o entidad, compara los recuentos de origen y destino, y luego toma muestras de ID estables y totales importantes. Para los archivos, registra nombres, tamaños y hashes criptográficos antes y después de la transferencia. El artefacto puede ser tan sencillo como:

entity,source_count,target_count,status
customers,1842,1842,pass
orders,9714,9714,pass
attachments,2281,2279,fail

Ese recuento fallido de adjuntos explica exactamente por qué los equipos ensayan. Sin una importación medida, la gente descubre documentos ausentes después de cancelar la cuenta antigua.

La complejidad de los flujos revela primero el techo

La complejidad se convierte en una señal de migración cuando el flujo contiene estado, excepciones, concurrencia o trabajo de larga duración que la herramienta no puede representar con claridad. El número de pantallas es una mala medida. Un directorio de veinte páginas puede ser sencillo, mientras una sola pantalla de aprobación puede ocultar reintentos, límites de tiempo, autoridad delegada y ediciones en conflicto.

Traza el flujo importante como estados y transiciones. Indica quién puede activar cada transición, qué datos modifica, qué ocurre si falla y si la acción puede ejecutarse dos veces sin riesgos. Si el mapa no puede implementarse sin automatización duplicada, fórmulas ocultas o personas reparando el estado, la aplicación ha cruzado el límite cómodo de la plataforma.

Considera una aprobación de pedido que cobra a un cliente cuando un responsable acepta un descuento. La versión sin código envía un webhook, no recibe respuesta antes de agotar el tiempo de espera y marca la tarea como fallida. Sin embargo, el servicio de pagos completa el cobro. Un usuario vuelve a intentarlo y al cliente se le cobra dos veces porque el flujo no tiene una clave de idempotencia ni un registro duradero del primer intento. Un reembolso manual oculta el fallo de diseño hasta que aumenta el tráfico.

Un backend convencional puede dar a esa operación un contrato explícito:

POST /orders/817/charge
Idempotency-Key: 817-approved-v3

202 Accepted
{"operation_id":"op_2941","status":"pending"}

La función importante no es la sintaxis del endpoint. El servidor guarda la clave de idempotencia, devuelve la misma operación ante un reintento y deja que un worker termine el cobro. La interfaz puede mostrar pendiente, completado o fallido sin fingir que una solicitud de red es instantánea.

No migres solo porque un flujo tenga muchas ramas. Las herramientas visuales suelen manejar bien las bifurcaciones. Migra cuando nadie puede describir las reglas de ejecución, observar un trabajo atascado, repetir una acción segura o probar una excepción sin tocar producción. El código fuente ayuda porque las reglas pueden convertirse en funciones y pruebas versionadas, pero el equipo debe seguir diseñándolas.

Las integraciones personalizadas necesitan contratos, no un recuento de conectores

Sustituye la herramienta cuando una integración crítica para el negocio necesita un comportamiento que su conector no puede expresar ni verificar. Un catálogo extenso de conectores no resuelve esto. Las preguntas difíciles abarcan autenticación, paginación, límites de tasa, reintentos, cambios de versión, webhooks, cuerpos de error y la responsabilidad sobre los mensajes fallidos.

Haz un inventario de integraciones según sus consecuencias. Una sincronización de boletines puede tolerar un retraso. Un cálculo de impuestos, una reserva de inventario, una verificación de identidad o una actualización de pago pueden exigir una respuesta exacta y una vía de recuperación. Para cada una, escribe los campos de solicitud y respuesta, el tiempo de espera, la regla de reintento, el comportamiento de idempotencia, el responsable de las credenciales, la señal de monitorización y el procedimiento alternativo.

Los equipos suelen añadir un servicio de automatización entre la aplicación sin código y una API externa. Es razonable para una tarea pequeña y observable. Se vuelve caro cuando el servicio de automatización contiene el flujo real y la aplicación solo conserva las pantallas. Entonces, cambiar el nombre de un campo rompe una cadena repartida entre tres editores y ningún repositorio registra el cambio completo.

Un creador que exporta código fuente debe producir código de integración que un desarrollador pueda leer y probar. Pídele que coloque la llamada externa detrás de una interfaz pequeña, conserve las credenciales en la configuración de entorno, registre un identificador de correlación y convierta los errores específicos del proveedor en errores de aplicación. Después desconecta el entorno de pruebas externo y confirma que la aplicación falla de la forma prometida. Las capturas de la ruta feliz no prueban una integración.

OpenAPI puede documentar operaciones HTTP, entradas, salidas y esquemas de autenticación, pero un cliente generado no decide la recuperación del negocio. El equipo aún debe especificar si un tiempo de espera implica reintentar, esperar un webhook, pedir ayuda a una persona o cancelar la operación. Mantén esa política en el código y las pruebas de la aplicación, en vez de enterrarla en la configuración de un conector.

El traspaso al desarrollador empieza antes de que llegue

Un traspaso al desarrollador funciona cuando un nuevo ingeniero puede explicar, ejecutar, probar y modificar el sistema a partir del repositorio y su documentación. Contratar a un desarrollador después de exportar no convierte mágicamente el código generado en un producto mantenido. El equipo saliente debe conservar las decisiones que la herramienta visual guardaba de forma implícita.

Prepara un paquete de traspaso mientras la gente aún recuerda la aplicación. Debe incluir un mapa del sistema, diccionario de datos, tabla de roles y permisos, lista de entornos, procedimiento de implementación, responsables de servicios externos, modos de fallo conocidos y el motivo de las reglas inusuales. Acompáñalo de acceso a la herramienta actual durante el tiempo suficiente para que el desarrollador compare comportamientos.

El código generado necesita una revisión más estricta que el código escrito durante un proceso de ingeniería prolongado, porque la generación optimiza por producir un resultado ahora. Busca reglas duplicadas, componentes sobredimensionados, comprobaciones de autorización ausentes, errores ignorados, dependencias con un propósito poco claro y pruebas que solo afirman que una página se muestra. Nada de esto condena automáticamente la exportación. Determina el presupuesto de estabilización.

Da al desarrollador entrante un cambio representativo antes de comprometerte con la migración. Una buena prueba cruza la interfaz, la lógica de negocio, la base de datos y la implementación sin ser enorme, como añadir un motivo de aprobación obligatorio e incluirlo en un registro de auditoría. Mide lo que el desarrollador tuvo que reconstruir. Si el cambio obliga a volver al creador por un comportamiento no documentado, el traspaso no está completo.

La propiedad también significa aceptar el mantenimiento rutinario. Alguien debe revisar actualizaciones de dependencias, renovar credenciales, vigilar trabajos fallidos, hacer copias de seguridad de los datos, probar restauraciones y responder a informes de seguridad. Un creador puede reducir el esfuerzo necesario para crear la aplicación. No puede hacer que una aplicación operada no tenga responsable.

La migración gradual suele superar a una reescritura

Migra un límite cada vez cuando el sistema actual sigue funcionando y sus datos pueden conciliarse. Las reescrituras completas parecen limpias porque posponen la coexistencia, pero también posponen la retroalimentación. El equipo dedica meses a reproducir comportamientos de los que los usuarios ya dependen, incluidos comportamientos que nadie documentó.

Elige una separación con una entrada y salida claras. Buenos primeros candidatos incluyen una vista de informes de solo lectura, un trabajo de generación de documentos, un nuevo portal de clientes o una integración problemática. Evita empezar por la autenticación o la transacción central, salvo que sean el motivo inmediato de salida. Afectan a demasiadas suposiciones a la vez.

Una secuencia segura tiene cuatro fases:

1. Exportar y reproducir la aplicación actual fuera del creador original.
2. Colocar el nuevo componente junto al antiguo y alimentarlo con datos copiados o de solo lectura.
3. Comparar resultados, tasas de error y comportamiento de usuarios mientras la ruta antigua sigue disponible.
4. Mover las escrituras detrás de una interfaz controlada, conciliarlas y retirar la ruta antigua cuando cierre la ventana de reversión.

La escritura dual merece desconfianza. Escribir cada cambio en las bases de datos antigua y nueva parece un puente sencillo, pero un fallo parcial crea dos verdades. Si la coexistencia exige escritura dual, colócala detrás de un servicio, registra un ID de operación, reintenta con seguridad y ejecuta un trabajo de conciliación. Mejor aún, conserva un sistema como autoritativo y replica los cambios hacia fuera hasta el cambio definitivo.

Las instantáneas y la reversión pueden reducir el riesgo de modificar aplicaciones generadas. Koder.ai admite exportación de código fuente, implementación y hosting, instantáneas y reversión, de modo que un equipo puede probar una ruta exportada mientras conserva un punto de recuperación. Estas capacidades solo ayudan cuando el equipo ensaya la restauración y sabe qué cambios de base de datos no deshará una reversión.

El trabajo gradual no siempre es más barato. Pagar por dos sistemas, sincronización temporal y soporte duplicado puede superar una reescritura breve cuando la aplicación es pequeña y se entiende bien. Estima la coexistencia de forma explícita en vez de ocultarla dentro del presupuesto de migración.

Una reescritura se justifica en casos más concretos

Reescribe la aplicación cuando el modelo existente está tan equivocado que conservarlo arrastraría el defecto a cada incremento. Esto ocurre cuando las entidades principales carecen de identidades estables, los permisos dependen de reglas dispersas por las pantallas, cada flujo modifica registros compartidos directamente o el código exportado no puede ejecutarse sin un entorno propietario.

Una reescritura también puede ganar cuando el producto es realmente pequeño. Si el equipo puede enumerar cada pantalla, regla, integración y entidad de datos en pocas páginas, y los usuarios aceptan una breve congelación de cambios, crear el destino una sola vez puede costar menos que construir un puente temporal. Verifica esa simplicidad con un inventario. La familiaridad suele hacer que una aplicación enredada parezca más pequeña de lo que es.

No uses una reescritura para evitar estudiar el sistema antiguo. Las fórmulas más feas pueden contener excepciones contractuales. Un campo que parece no usarse puede alimentar una exportación mensual. Un permiso extraño puede existir porque dos clientes comparten una cuenta. Trata el comportamiento actual como evidencia y decide después qué conservar, cambiar o eliminar.

Escribe pruebas de aceptación sobre resultados antes de implementar. Usa ejemplos de registros reales anonimizados: un usuario con dos roles puede aprobar una región, pero no otra; un pedido cancelado no puede cobrarse; un adjunto importado conserva su propietario y hora de creación. Estas pruebas dan a un creador de IA o a un desarrollador humano un objetivo más difícil de malinterpretar que una pila de capturas de pantalla.

Establece una regla de parada para la reescritura. Si el destino no supera un conjunto fijo de pruebas de aceptación o no puede importar una copia de datos representativa antes de la fecha de decisión, amplía el contrato antiguo y reduce el alcance. No fuerces un lanzamiento porque el reemplazo haya consumido su presupuesto. El coste hundido no hace seguro un sistema incompleto.

Los contratos y el cumplimiento pueden adelantar la fecha límite

Un requisito contractual o normativo puede justificar la migración antes de que los límites de funciones sean dolorosos. El detonante no es un miedo general al cumplimiento. Es una obligación específica que la herramienta actual no puede satisfacer, documentar ni dejar que el equipo verifique.

Empieza por la cláusula contractual o el control y sigue su relación con el comportamiento de la aplicación. Una cláusula de residencia de datos plantea preguntas sobre la base de datos principal, réplicas, copias de seguridad, almacenamiento de archivos, acceso de soporte, registros y subprocesadores. Un requisito de auditoría plantea preguntas sobre identidad de eventos, marcas de tiempo, retención, acciones de administradores y si los usuarios pueden alterar el historial. Un compromiso de eliminación plantea preguntas sobre registros derivados y copias de seguridad, no solo sobre la fila visible del cliente.

Pide pruebas por escrito al proveedor, pero separa los controles del proveedor de los controles de la aplicación. Una plataforma puede proteger su infraestructura mientras la aplicación concede acceso administrativo a todas las cuentas del personal. Puede ofrecer hosting regional mientras una integración envía datos personales a un servicio en otra región. El equipo es responsable de esas decisiones de aplicación aunque no controle el entorno de ejecución.

El código fuente no crea cumplimiento por sí mismo. Exportar una aplicación puede aumentar las obligaciones del equipo, porque ahora elige infraestructura, controles de acceso, política de copias de seguridad, retención de registros y calendario de parches. Migra solo cuando el modelo operativo de destino asigne cada obligación a un rol concreto y aporte pruebas que auditores o clientes puedan inspeccionar.

La revisión de seguridad debe centrarse en los límites que cambian durante la migración. Enumera endpoints públicos, operaciones privilegiadas, secretos, flujos de datos personales y roles administrativos. Compara los diseños antiguo y nuevo, y después prueba la autorización en el servidor. Ocultar un botón en la interfaz nunca demuestra que la operación subyacente rechaza una solicitud no autorizada.

Usa una pequeña matriz de permisos como artefacto de aceptación:

operation,member,manager,administrator
view_own_order,allow,allow,allow
approve_discount,deny,allow,allow
export_all_customers,deny,deny,allow

Convierte cada fila en una prueba automatizada. Si un rol u operación no tiene un resultado explícito, la política está incompleta. Este ejercicio suele descubrir permisos que el editor sin código dispersó por páginas y flujos.

El calendario contractual afecta al plan de migración. Una renovación, el lanzamiento en un mercado nuevo o una revisión de seguridad de un cliente pueden crear una fecha límite rígida. Planifica hacia atrás desde las pruebas necesarias, no desde el anuncio de lanzamiento deseado. Deja tiempo para una restauración de datos representativa, revisión de accesos, pruebas de penetración cuando corresponda, aceptación de usuarios y un ensayo de reversión.

No prometas que una pila nueva cumplirá en todas partes porque puede ejecutarse en varias regiones. Koder.ai puede ejecutar aplicaciones en distintos países, lo que puede ayudar a un equipo a cumplir requisitos de residencia, pero el equipo debe elegir la ubicación correcta e inspeccionar cada servicio que recibe datos. Registra esas decisiones en el documento de arquitectura y verifícalas en el entorno implementado.

Compara el coste total de propiedad, no los precios de suscripción

La opción más barata es la que tiene el menor coste esperado de cambio, operación y salida durante el periodo que el equipo puede prever razonablemente. Comparar una suscripción sin código con una factura de hosting ignora el tiempo de desarrollo, las soluciones provisionales, la respuesta a incidentes, los límites del proveedor, el trabajo de migración y el coste de retrasar trabajo solicitado.

Elabora la estimación a partir del trabajo observado. Incluye tarifas de plataforma, conectores de pago, servicios de automatización, operaciones manuales, tiempo de soporte, recuperación de trabajos fallidos y el impacto en ingresos o contratos de cambios bloqueados. Para la opción con código propio, incluye estabilización, hosting, monitorización, copias de seguridad, mantenimiento de seguridad, disponibilidad de desarrolladores y futuras actualizaciones.

Usa rangos porque las estimaciones de migración contienen incertidumbre. Registra un caso bajo, esperado y alto para cada elemento grande, e identifica qué supuesto cambia la decisión. Si el resultado depende por completo de una exportación perfecta o de una migración de datos de una semana, paga por probar ese supuesto antes de aprobar el proyecto.

El valor de opción del código fuente merece una línea en la decisión, aunque no debe convertirse en ahorro imaginario. El código fuente permite al equipo cambiar de proveedor, contratar otros desarrolladores, inspeccionar el comportamiento y ejecutar la aplicación en otro entorno. Esa flexibilidad tiene valor práctico cuando cambian los contratos, las reglas de residencia o las integraciones. Tiene poco valor si nadie puede mantener el repositorio.

Separa los costes únicos de los recurrentes. Una migración gradual puede parecer peor en el primer trimestre porque incluye coexistencia y luego resultar más barata cuando desaparece el trabajo manual. Una reescritura puede parecer barata en una estimación de construcción mientras concentra el riesgo en el lanzamiento. Coloca ambas opciones en una línea de tiempo con fechas explícitas para retirar los servicios antiguos.

Toma la decisión con pruebas de un piloto

Un piloto de dos semanas debe atacar el supuesto más arriesgado, no producir la pantalla más bonita. Exporta una parte representativa, restaura sus datos, implementa un flujo o integración difícil, implántalo fuera de la plataforma original y pide a un desarrollador que no lo haya creado que haga un cambio.

Puntúa el resultado frente a criterios de aprobado o suspendido acordados antes del piloto:

• La aplicación exportada se compila con comandos documentados.
• Un conjunto de datos representativo se importa con recuentos y archivos conciliados.
• La operación difícil maneja fallos de tiempo de espera, reintentos y permisos.
• Un nuevo desarrollador completa el cambio de traspaso sin estado oculto en el editor.
• El equipo puede implementar, observar, hacer copias de seguridad y restaurar el resultado.

No diluyas un requisito de salida fallido con promedios. Una interfaz preciosa no compensa una base de datos imposible de exportar, y una generación rápida no compensa una autorización que nadie puede verificar. Marca los criterios obligatorios por separado de las preferencias.

Registra el piloto como un registro de decisión, no como un vídeo de demostración. Conserva el commit de exportación, los comandos de configuración, el informe de importación, la salida de pruebas fallidas, la configuración de implementación, el tiempo invertido y cada intervención manual. Pide al proveedor del creador que aclare por escrito cualquier dependencia oculta. Si el equipo no puede reproducir el resultado satisfactorio una semana después, el piloto ha mostrado una ruta frágil en lugar de un modelo operativo.

Incluye a quienes darán soporte a la aplicación después del lanzamiento. Un fundador puede aceptar pasos de implementación poco pulidos que un desarrollador de guardia no puede repetir con seguridad, mientras un desarrollador puede restar importancia a una excepción de back office que cuesta horas cada semana a un equipo de operaciones. Cada grupo debe aprobar los criterios que tendrá a su cargo. El desacuerdo es útil cuando aparece antes de financiar la migración, no durante el cambio definitivo.

Quédate con la herramienta sin código cuando el piloto demuestre que los límites actuales son incómodos pero manejables, que ser propietario de la exportación añadiría más mantenimiento del que elimina y que el trabajo previsto encaja en la plataforma. Renegocia la fecha de decisión cuando ocurra un detonante conocido, como un mercado regulado nuevo, una integración central o la incorporación del primer desarrollador a tiempo completo.

Muévete cuando el piloto demuestre que el código fuente puede sostenerse por sí mismo y el backlog muestre trabajo repetido ligado a los límites de la plataforma. Elige una separación gradual salvo que el inventario pruebe que la aplicación es pequeña o que su modelo no tiene arreglo. La decisión está lista cuando el equipo puede nombrar qué controlará al otro lado: el repositorio, los datos, la implementación, los fallos y la libertad de modificarlos.