Para talleres de rescate y due diligence
Reconstruí una app vibe-coded rota
sobre una base que pasa due diligence
Keys expuestas, webhooks no idempotentes, gaps de RLS — ya conocés los síntomas. No parches el loop. Migrá a una fundación DDD-layered, testeada y tipada que el agente no puede volver a romper.
La IA que la construyó no puede refactorizar más allá de su context window
Esto lo sabés mejor que nosotros: "the AI that built it cannot reliably refactor it because the codebase has outgrown its effective context window." (morphllm) Después de seis meses de vibe coding, los equipos reportan que hubo que reescribir cerca del 40% del codebase y que la deuda técnica subió 340%. Parchar con el mismo agente que escribió la deuda solo suma más.
Un landing pad que pasa la auditoría que vos mismo correrías
Layering DDD, lint-enforced
El código de domain no puede importar Express, Prisma ni infraestructura — enforzado como regla de ESLint, no como guideline. Fronteras claras adentro de las que un agente puede operar sin erosionarlas.
E2E en CI + contratos tipados
Los flujos golden-path de Playwright gatean cada PR, y un contrato OpenAPI tipado compartido (regenerado y chequeado en CI) evita que cliente y server driften.
Trazable por diseño
Un event bus con outbox durable, más OpenTelemetry y Sentry, te dan el audit trail y la operabilidad que busca la due diligence.
Las categorías de seguridad que siempre encontrás abiertas — cerradas por default
Sin keys en el bundle del cliente
Los secrets viven en env del server, nunca se shippean al navegador — lo primero que grepeás en el intake.
Webhooks idempotentes
Las compras son idempotentes sobre externalOrderId y se entregan por un outbox durable — un webhook duplicado no puede cobrar dos veces.
Sesiones que respetan un reset
Reseteás una contraseña y las sesiones existentes se revocan vía BetterAuth; el token viejo deja de funcionar.
Tenant isolation org-scoped
Un tenant-isolation guard devuelve 404 entre organizaciones — sin política de RLS que olvidar o invertir.
Una migración le gana a un loop de parches factura-tras-factura
Un rescate que parcha síntomas vuelve a facturar la próxima vez que el agente toca el código. Migrar una vez a una base que el agente no puede volver a romper es más barato para el cliente y más definitivo para vos — y es una mejor historia para contarle a un inversor que "lo seguimos arreglando".
Un stack de referencia sobre el que estandarizar
Si auditás apps de Lovable, Bolt y Replit antes de fundear, necesitás un destino confiable al que apuntar a los clientes — un stack que puedas recomendar y estandarizar. DDD, tests, contratos tipados, un event bus audit-friendly y observabilidad son exactamente los casilleros que tilda tu checklist.
Asociate con nosotros
Partnership de rescate y agencias
Queremos a los talleres de rescate y due diligence como canal. Recomendalo a los clientes que rescatás, estandarizá tus reconstrucciones sobre una sola base, y escribinos para asociarnos.
Licenciamiento para reconstrucciones de clientes
Revisá la página de pricing para los términos comerciales actuales antes de armar una práctica de reconstrucción sobre esto.
FAQ de reconstrucción y due diligence
¿Por qué migrar en vez de refactorizar la app existente?+
¿Qué significa "pasa due diligence" acá, concretamente?+
¿Cuál es el stack?+
¿Podemos asociarnos o revender?+
El destino de reconstrucción, no otro rescate.
Migrá una vez a una fundación DDD, testeada y tipada que el agente no puede volver a romper — y pasá la auditoría a la primera.