Bolt → una base que sobrevive al mes dos

Bolt armó tu MVP en un finde.
El finde se terminó.

La velocidad de Bolt viene de nunca frenar a estructurar nada — cada prompt apila código sobre un proyecto que nació sin arquitectura. Es un trade justo para un demo, y fatal para la lista de features del mes dos, cuando cada cambio empieza a costar el doble. useDeploy es donde el MVP crece: módulos acotados, fronteras que rompen el build cuando se cruzan y contratos que atrapan el drift antes que tus usuarios.

El mecanismo: velocidad sin paredes portantes

El pitch de Bolt es la app entera, en el navegador, ya — y cumple, precisamente porque se saltea todo lo que hace que una app se pueda cambiar después. No hay separación entre UI, API y acceso a datos, porque separar cuesta prompts. Nada se reorganiza jamás, porque reorganizar no es una feature que pediste. La curva de deuda que esto produce está bien documentada: "la deuda técnica no se paga, se le sigue sumando, y en algún momento del futuro alguien la va a venir a cobrar" (news.ycombinator.com). Y el cobrador llega con un giro específico de las apps hechas con IA — el doom loop: pasado cierto tamaño, la IA que la construyó ya no puede refactorizarla de forma confiable: el codebase superó la context window efectiva del modelo (morphllm.com). La herramienta que creó el desorden es estructuralmente incapaz de limpiarlo. Y vos nunca aprendiste el codebase, porque nunca lo escribiste.

Cómo se manifiesta el spaghetti de Bolt

Arreglás una cosa, rompés dos

Las features de Bolt comparten archivos, estado y helpers improvisados, así que ningún cambio es local. Presupuestás una hora para un fix y gastás la tarde en daños colaterales.

La API está donde la puso un prompt

Endpoints desparramados entre archivos, cada uno validando input a su manera — o directamente no validando. No hay un solo lugar donde ver qué expone tu backend.

Un schema hecho de parches

Columnas agregadas prompt a prompt, nombres que driftean, relaciones implícitas en vez de declaradas. La base registra la historia de tus prompts, no el diseño de tus datos.

Misma lógica, bugs distintos

El cálculo del total del pedido existe en tres lugares con tres redondeos. Los usuarios ven el que les toque según su click path.

El agente regenera en vez de reparar

Pedís un fix y reescribe el archivo entero, llevándose tus parches manuales. El progreso deja de ser acumulativo.

Debuggear pesa más que construir

La señal de que la fase demo terminó: los prompts que antes sumaban features ahora generan sobre todo disculpas y reverts parciales.

La pared: un build que falla cuando las fronteras se rompen

Esta es la diferencia entre una convención y una pared. En useDeploy el layering DDD lo enforza el flat-config de ESLint: código de domain que importa Prisma o Express rompe el build. Un agente no puede meter "serviciamente" una llamada a la base adentro de tus reglas de negocio — CI rechaza la edición antes de que pueda volverse arquitectura. En Bolt, el desorden se acumulaba en silencio; acá falla a los gritos y nunca aterriza.

$ bun run lint — la pared de fronteras
 1  $ bun run lint
 2  
 3  apps/server/src/modules/billing/domain/subscription.ts
 4    error  '@prisma/client' import is banned in domain/
 5           ddd-boundaries/no-infra-in-domain
 6  
 7  apps/server/src/modules/iam/domain/session.ts
 8    error  'express' import is banned in domain/
 9           ddd-boundaries/no-framework-in-domain
10  
11  ✖ 2 problems (2 errors, 0 warnings)
12  
13  CI: lint ✗ — merge blocked.

La estructura a la que estás portando

Bounded contexts en vez de una gran pila

iam, tenancy, billing, storage, ai y webhooks son módulos separados con capas de domain, application, infrastructure e interface — cada capability aislada, cada dependencia apuntando hacia adentro.

Una sola fuente de verdad para cada payload

@app/contracts guarda los schemas Zod compartidos; openapi-fetch tipa el cliente desde el propio output OpenAPI del server; el gate api-types-fresh hace fallar CI ante el drift. La clase de bug del 400-en-producción queda cerrada.

Merges gateados por 450+ tests

Cobertura unit e integración más un gate E2E de Playwright. En Bolt, las regresiones shippeaban en silencio; acá fallan un check con nombre.

Un outbox para los side effects

Emails, webhooks y jobs de sync pasan por un event bus con outbox durable — con retries, observables y fuera de tus request handlers.

Un manual de operaciones en el repo

CLAUDE.md codifica las reglas que los agentes deben seguir; los docs de arquitectura en /docs explican el porqué. El próximo prompt hereda el diseño en vez de re-derivarlo.

El camino de migración: triage, no rewrite

Salir es un triage, no un rewrite. Descargá tu proyecto — el código de Bolt exporta como un stack web estándar y siempre fue tuyo — y ordenalo en tres pilas. Pantallas y componentes: quedátelos; son React y cargan tu UX validada. Lógica de producto: extraela; es el código que vale la pena tener, y se muda a un bounded context donde tests y lint la sostienen en su lugar. Plomería — el auth improvisado, el webhook handler que un prompt escribió a las 2 a.m., el código de uploads: borrala, porque useDeploy shippea versiones endurecidas y testeadas de todo eso. Portá una feature a la vez, y seguí usando un agente para el port mismo; las fronteras aguantan sin importar quién tipea. La velocidad del MVP-de-finde vuelve — solo que deja de pedir prestado contra el mes dos.

Preguntas de migración desde Bolt

¿Pierdo la velocidad que hacía que Bolt valiera la pena?+
No — la relocalizás. La parte lenta de un SaaS nunca fueron las features de tu producto; son auth, orgs, billing y la plomería alrededor, y eso viene pre-construido y testeado. Los agentes siguen generando tu código de features a velocidad de prompt — solo que adentro de fronteras que rompen el build al cruzarse.
¿Puedo siquiera sacar mi código de Bolt?+
Sí. Los proyectos de Bolt exportan como un stack web estándar que podés descargar o pushear a GitHub — el código siempre fue tuyo. Lo que dejás atrás no es el código: es la manera sin estructura en que se acumuló.
¿Cuánto de mi proyecto de Bolt sobrevive la mudanza?+
Pensalo en tres pilas. UI: sobrevive casi toda — es React y viaja bien. Lógica de producto: sobrevive pero se muda — se re-alberga en un bounded context con tests alrededor. Plomería: se borra con alegría, porque la base shippea versiones endurecidas del auth, el billing y los uploads que Bolt improvisó.
¿Qué impide que un agente haga el mismo desorden en la base nueva?+
Los merge gates. El lint de fronteras bloquea violaciones de capas, api-types-fresh bloquea el payload drift entre server y cliente, y 450+ tests más un gate E2E de Playwright bloquean regresiones. En Bolt el desorden se acumulaba en silencio; acá falla a los gritos antes de aterrizar.

Una licencia. Dos formas de tenerla.

CORE

Founder

$99pago único

Un snapshot congelado de UseDeploy. Tuyo para siempre, sin updates.

  • Descarga del zip con versión frozen
  • Código completo, uso comercial, proyectos ilimitados
  • Los 800+ tests · todas las páginas de docs
  • Refund a 14 días
RECOMMENDED

LATEST + UPDATES

Lifetime

$199$249pago único

Siempre el último UseDeploy. Re-descargá cada release, gratis.

  • Zip de la última versión — re-descargable para siempre
  • Cada release futuro sin cargo extra
  • Soporte Discord priority
  • Los 800+ tests · todas las páginas de docs
  • Refund a 14 días

Quedate con la velocidad del finde. Sacate de encima el colapso del mes dos.

Portá tu MVP de Bolt a una base donde la plomería está hecha, las fronteras rompen el build y 450+ tests custodian cada merge.