Backends Java listos para producción, generados desde tu schema SQL. Horas, no meses.
Un backend listo para producción, 95–100% tested, en horas. Hexagonal, vertical slicing, monolito modular o microservicios. Tu equipo construye la lógica de negocio encima.
Lo ves funcionando y pruebas cada endpoint antes de pagar nada.
Tu schema es confidencial. NDA a petición.
- Java 25
- Spring Boot 4.1
- Hexagonal
- Vertical slicing
- ArchUnit + mutation testing
Míralo en acción
De un schema SQL a un backend tested y arrancando
Un recorrido breve: entra el schema, sale un backend hexagonal. Generado y verificado.
La suposición equivocada
“Contrato devs + IA y lo construyo más rápido y barato.”
Razonable, y equivocado. Antes de una sola regla de negocio, se van semanas o meses en setup, decisiones de arquitectura, scaffolding de cada entidad en cada capa, y la base de tests. Justo esa parte es la que se pudre en acoplamiento oculto.
Esa parte es la que AlveoForge entrega, correcta y tested, en horas. No comparamos contra tu build entero. Tu lógica de negocio es tuya; comparamos contra la capa estructural production-ready que cualquier equipo paga igual.
Por qué es diferente
Por qué un equipo + IA no puede replicar esto
La IA deriva a patrones legacy
La IA aprendió sobre todo de código público — MVC en capas clásico. Le pides hexagonal real y, sin supervisión, deriva hacia lo que conoce. Parece hexagonal; no lo es.
Determinista, no probabilística
Mismo schema, mismo output, siempre. Lo auditas una vez y luego verificas que cada build coincide. Un equipo + IA produce algo distinto en cada intento.
Se arregla en el origen
Un bug encontrado una vez queda arreglado para todas las generaciones futuras. Convenciones y estructura impuestas por construcción, no esperando que la revisión de código pille la deriva.
Dónde encaja
Cualquiera te da una primera entidad limpia
Las arquitecturas no mueren en el diseño; mueren en la entidad 200, a las 6 de la tarde, bajo un deadline. Esto es lo que aguanta esa línea y lo que no, comparando la salida por defecto y no el mejor caso al que llega cada herramienta con trabajo extra.
| AlveoForge | JHipster | Scaffold / plantilla | Senior + copiloto IA | |
|---|---|---|---|---|
| Arquitectura | Hexagonal real, puertos y adaptadores, un vertical slice por entidad | En capas: controller / service / repository | Lo que montes tú | Deriva hacia MVC en capas |
| Consistencia a escala | Determinista: la entidad 200 es igual que la primera | Consistente, pero en capas | Tan consistente como se mantenga el equipo | Deriva entidad a entidad, en silencio |
| Modelo de persistencia | FK escalares, sin grafo JPA entre capas; ?expand sin N+1 | Grafo JPA bidireccional | A tu criterio | Normalmente un grafo JPA, N+1 por defecto |
| Tests | Pirámide de 4 capas, 95–100% de cobertura (JaCoCo) | Tests generados básicos | Los escribes tú | Tests parciales, rara vez medidos |
| Puertas de calidad | ArchUnit + mutation testing (PIT) en CI | Ninguna por defecto | Ninguna | Ninguna |
| Migraciones y BD existente | Flyway o Liquibase con paridad, más adopción brownfield; tu DDL es la fuente de verdad | Liquibase | A mano | Ad hoc |
| Escala | Validado a 1.000+ tablas → microservicios | Entidad a entidad, sin contrato de escala | — | Se degrada según crece el schema |
| Propiedad | Maven y Spring estándar, tuyo, sin dependencia de nosotros en runtime | Tuyo, dentro de las convenciones del framework | Tuyo | Tuyo |
Todas son capaces en las manos adecuadas. El eje es qué obtienes por defecto y qué sigue aguantando en la entidad 200.
Cómo funciona
Guiado, de principio a fin
- 1
Llamada inicial
Compartes tu schema SQL; lo revisamos juntos y detectamos casos límite.
- 2
Sesión de configuración
Completamos juntos el fichero de enrichment — módulos, límites, opciones. Tú pones el dominio; yo la traducción técnica.
- 3
Generación y verificación
AlveoForge genera el backend completo; la salida se verifica antes de compartir nada.
- 4
Prueba antes de pagar
Una instancia en vivo y un preview interactivo de la API (Swagger). Cada endpoint, testeable, antes de pagar.
- 5
Entrega
Cuando estás satisfecho, el código aterriza en un repo privado de GitHub, listo para clonar.
En números
La diferencia, medida
Validado en un schema real de 300+ tablas.
Alcance
Qué recibes
Incluye
- ✓Backend completo y ejecutable en un repositorio privado
- ✓Arquitectura hexagonal real + vertical slicing
- ✓CRUD completo, operaciones individuales y en lote, y expand de relaciones al leer (?expand=)
- ✓Cobertura completa de tipos SQL: arrays, enums, JSONB, UUID, timestamptz, precisión numérica, binario (bytea), claves compuestas y foráneas, herencia y particiones
- ✓PostgreSQL · MongoDB · caché Redis · outbox transaccional
- ✓Migraciones de BD (Flyway o Liquibase) + adopción brownfield de tu base de datos existente
- ✓Auth JWT, refresh tokens y verificación por email + perfiles dev / pre / prod
- ✓Suite de tests en una pirámide de cuatro capas: caminos de éxito y error (95–100%)
- ✓Monolito modular o microservicios, a tu elección, sin lock-in
- ✓Código 100% tuyo + 30 días de soporte post-entrega
No incluye
- ✕El sistema de generación (sigue siendo propietario)
- ✕Autorización por fila (quién accede a qué registro): tus políticas encima
- ✕Tu lógica de negocio y reglas propias del dominio (p. ej. regex)
- ✕Integraciones con servicios de terceros
A medida que tu proyecto crece, cada feature se genera como un vertical slice independiente, que se añade junto a tu código sin tocar lo que tu equipo ya construyó. Hexagonal aísla el dominio de la base de datos, el framework y el delivery; el vertical slicing mantiene cada feature cohesionada, así que lo que cambia junto, vive junto. Eso es lo que permite que el backend escale en orden y siga siendo rápido de tocar, en vez de degenerar en el acoplamiento enmarañado que congela equipos años después.
Bajo el capó
Dentro de cada entidad generada
La mayoría de herramientas generan cascarones vacíos: carpetas hexagonales, CRUD de pega, sin comportamiento real ni tests. Esto es lo que AlveoForge genera, y verifica, para cada entidad.
Dos motores de migración — y tu base de datos adoptada
Flyway o Liquibase con paridad total. O lo apuntas a tu base de datos de producción existente y se adapta (brownfield). Tu DDL es la fuente única de verdad: sin deriva de esquema.
Single y bulk, en todo
Cada entidad trae operaciones individuales y en lote: create-many, by-ids, updates masivos, cada una validada y tested.
Expand de relaciones al leer
Los GET hidratan entidades relacionadas a demanda entre vertical slices, hasta dos niveles por defecto (ajustable), sin N+1 ni grafo JPA expuesto entre tus capas.
El contrato HTTP completo, testeado
Cada endpoint se prueba en éxito y en fallo, incluidos los caminos de error. En la pirámide de cuatro capas, asertando métodos, líneas y ramas.
Login, hashing, JWT y refresh tokens
Entidad de login real, hash de contraseña en el borde de persistencia, JWT (en proceso o HTTP entre servicios), refresh tokens inline o en tabla dedicada.
Las decisiones de arquitectura, aplicadas
FK escalares (sin grafo ORM filtrándose entre capas), N-N como entidades join-table de primera clase, soft-delete desde columnas de auditoría, claves compuestas, naturales e identity. Las decisiones que separan «compila» de «es correcto».
Cómo es comprar
Ves tu backend antes de pagarlo.
El primer pago es una señal, no el proyecto entero. Una consultora no puede igualarlo, porque está generado, no escrito a mano.
- 1
Una llamada
Nos cuentas tu sistema y nos pasas tu schema SQL.
- 2
Recibes el presupuesto
Quince días para decidir. Sin prisa ni presión.
- 3
Generamos tu backend
A partir de tu schema: hexagonal, tested, ejecutable.
- 4
Lo ves funcionando, gratis
Un enlace privado: tu API en vivo, su Swagger, su informe de tests y su cobertura JaCoCo. Todavía no has pagado nada.
- 5
Primer tramo
Un primer conjunto de tablas. Eliges cuáles, y te recomendamos las más difíciles. Lees el código real antes de comprometer el resto.
- 6
El repo es tuyo
Segundo pago, y el repositorio completo es tuyo.
Por qué podemos hacer esto y una consultora no
Una consultora no puede construirte el backend gratis solo para enseñártelo. Nosotros sí: el coste marginal de generarlo tiende a cero. No es “somos más rápidos”; es una asimetría estructural.
Roadmap
Lo entregado, y lo que viene
Entregado
- Arquitectura hexagonal real + vertical slicing
- Generación determinista: mismo schema, mismo output
- Monolito modular o microservicios desde el mismo schema
- Cobertura completa de tipos SQL estándar
- PKs compuestas, naturales y autogeneradas · N-N como recurso de primera clase
- Herencia y particiones declarativas de PostgreSQL
- Multi-store: PostgreSQL · MongoDB · caché Redis · outbox
- Separación lectura/escritura · datasources writer y reader — lecturas a réplicas y escrituras al primario, con una frontera transaccional en la aplicación (Unit of Work) — opt-in para dominios con mucha lectura
- Migraciones (Flyway / Liquibase) + adopción brownfield
- CRUD completo + operaciones en lote
- Expand de relaciones al leer (?expand=)
- Auth JWT, refresh tokens y verificación por email
- Seeding de reference-data y defaults obligatorios
- Pirámide de tests de 4 capas: éxito y error · 95–100% cobertura — unit · integration · component · e2e
- Arquitectura verificada en CI, con mutation testing — reglas ArchUnit verifican el hexágono; PIT comprueba que los tests cazan los fallos inyectados
- Validado en schemas de 300+ tablas
- Escala a GitLab 1.000+ tablas — estresando el pipeline en schemas muy grandes
- Capa de lectura GraphQL — alternativa al expand REST para grafos complejos
En marcha
- Salida al mercado — preparando AlveoForge para el lanzamiento público: web, demos y primeros clientes fundadores
Largo plazo
- Plataforma self-service — subir schema → preview → repo, sin llamada
- Más lenguajes y frameworks — NestJS, Python y C# (hexagonal), más allá de Java, y cualquier lenguaje a petición del cliente
- API reactiva opcional — Mono/Flux, opt-in para streaming / alto I/O
- Expand de árboles jerárquicos — árboles padre/hijo (auto-referencias) expandidos en lectura
Lo «Entregado» está disponible hoy en el servicio guiado Java / Spring Boot. «En marcha» y «Largo plazo» están en el roadmap, aún no disponibles.
Sobre el autor
Hecho por alguien que vivió el problema

Soy Álvaro. AlveoForge nació de un bloqueo que viví de cerca: un backend que funcionaba pero no tenía arquitectura real. Reescribirlo bien era la decisión de ingeniería correcta, pero implicaba congelar al equipo casi un año mientras los clientes pedían features nuevas ya. La lógica de negocio no era lo difícil; esa ya la teníamos. Lo que se comió el año fue reconstruir la estructura hexagonal y toda su suite de tests, entidad a entidad. Ninguna empresa puede permitirse parar tanto, y ese es justo el dilema que AlveoForge elimina. Pasé 14 meses convirtiendo arquitectura hexagonal real a escala en una fábrica determinista que entrega un backend listo para producción en horas, no meses. Soy su primer usuario, ya validado a escala en un sistema real. Si te convence, hablamos.
LinkedIn →FAQ
Respuestas por rol
General
¿Mi schema es confidencial?+
Sí. Se usa solo para construir tu backend, se trata como confidencial, y hay NDA a petición.
¿Qué tengo que aportar?+
Tu schema SQL para arrancar: la estructura (tablas, relaciones, constraints), no tus datos ni tu lógica de negocio. A partir de ahí hacemos una sesión guiada breve para recoger las decisiones de dominio que dan forma al resultado: separación en microservicios y sus nombres, si quieres MongoDB / Redis / patrón outbox, perfiles de entorno, etc. Tú traes el dominio; yo me encargo de la traducción técnica.
¿Qué recibo exactamente?+
Un backend listo para producción por entidad: hexagonal, tested, ejecutable. Tu lógica de negocio e integraciones se quedan con tu equipo. El código es 100% tuyo, sin lock-in.
¿Monolito o microservicios?+
A tu elección, desde el mismo dominio: monolito modular o microservicios (una app Spring Boot arrancable por módulo). Sin reescritura cuando cambies.
¿Recibo el sistema de generación?+
No. La fábrica sigue siendo propietaria. Recibes el output: código profesional y tested, 100% tuyo, que puedes mantener sin AlveoForge.
¿Cómo se fija el precio?+
Por proyecto, calculado sobre tu schema (tamaño y complejidad), no por tabla. El primer pago es una señal: ves tu backend funcionando sobre tu schema, con su Swagger y sus informes de tests, antes de pagar nada. Como referencia, la misma capa estructural construida en interno son seis a diez meses de un equipo.
¿De quién es el código generado?+
Tuyo por completo. Modifícalo, despliégalo, extiéndelo, reutilízalo en otros proyectos. Sin licencia, sin royalties y sin dependencia de nosotros en tiempo de ejecución. Lo único que sigue siendo nuestro es el generador.
¿Qué hacéis con nuestro schema?+
Se usa solo para construir tu backend, se trata como confidencial y se elimina tras la entrega. Nunca se comparte con terceros ni se usa para entrenar nada. ¿Prefieres enviar un schema anonimizado/renombrado (estructura sin nombres reales)? También nos vale.
Eres fundador único — ¿y si AlveoForge desaparece?+
El código es tuyo y no depende de nosotros: Maven estándar, Spring Boot estándar. Sigue compilando, ejecutándose y siendo mantenible estemos o no. Esa independencia es la garantía de continuidad.
Para tech leads
¿Hexagonal de verdad o MVC con carpetas hexagonales?+
Hexagonal real con vertical slicing: lógica de negocio aislada de base de datos, framework y delivery. Es la razón misma de la fábrica: los equipos con IA derivan a MVC en capas; esto no.
¿Cómo está estructurada la suite de tests?+
Como una pirámide de tests de cuatro capas: la taxonomía estándar del sector (Fowler / Clemson), y cada capa es su propio perfil de Maven. Unit prueba cada clase en aislamiento con sus colaboradores mockeados, rápido y determinista, la ejecución por defecto. Integration ejercita los adaptadores de persistencia contra una base de datos real (PostgreSQL, MongoDB, Redis) levantada con Testcontainers, no un sustituto en memoria. Component arranca el servicio entero en un puerto aleatorio y lo maneja por su frontera HTTP: contrato JSON, códigos de estado, validación, esquema real. End-to-end recorre un flujo de usuario completo con cada colaborador real, incluida la propagación por outbox y la verificación por email. No hay, deliberadamente, capa de contract de consumidor: el spec OpenAPI/Swagger es el contrato, y la capa component lo verifica.
¿La cobertura del 95–100% es real o tests vacíos?+
Métodos, líneas y ramas, medido con JaCoCo. Cada camino se ejecuta y se asertan resultados, no solo se recorre. La fuerza de los tests se verifica con mutation testing (PIT): inyecta fallos en el código y comprueba que los tests los cazan, con un mutation score del 95%+.
¿Los tests cubren los caminos de error o solo el camino feliz?+
Ambos. Cada endpoint se prueba en éxito y en fallo: 400 validación, 401 auth, 404, 415, incluidos los caminos de error. En la pirámide de cuatro capas, asertando métodos, líneas y ramas. Los tests vacíos de solo-camino-feliz son justo lo que no entregamos.
¿Qué operaciones tiene cada entidad?+
CRUD completo más lote: create, read (individual, paginado, by-ids), update, delete, create-many y updates masivos, con expand de relaciones al leer (?expand=…) entre slices, sin N+1 ni grafo JPA expuesto entre capas.
¿Cómo encaja con nuestra base de datos y migraciones actuales?+
Tu DDL es la fuente única de verdad, emitido como migración versionada. Eliges Flyway o Liquibase, ambos cableados con paridad, o lo apuntas a una base de datos de producción existente y se adapta (brownfield) sin reconstruir tu esquema. Hibernate corre en modo validate, así que las entidades se validan contra el esquema real al arrancar.
¿Puede mi equipo mantener código que no escribió?+
Sí. Un patrón repetido de forma consistente, código estándar y legible que cualquier dev Java extiende desde el día uno, más 30 días de soporte. Y es tuyo: sin dependencia de AlveoForge.
¿Qué pasa con mi código cuando regenero?+
La regeneración reproduce la versión de fábrica de una entidad, así que las ediciones manuales de ese mismo slice se sobrescriben. En la práctica regeneras para añadir entidades nuevas: como cada una es un vertical slice independiente, los slices nuevos entran junto al código que tu equipo ya escribió y editó, sin tocarlo. Tu lógica de negocio vive en sus propios slices y queda intacta.
¿Necesito un IDE o herramienta de build concreta?+
No. La salida es un proyecto Maven estándar: ábrelo en cualquier IDE (IntelliJ, VS Code, Eclipse, NetBeans…) o en ninguno. Compila, testea y ejecútalo directamente desde la terminal con el wrapper de Maven (./mvnw). Sin ataduras a editor, plugin ni proveedor.
¿Cuál es el stack?+
Java 25, Spring Boot 4.1, hexagonal + vertical slicing, PostgreSQL · MongoDB · Redis con outbox, auth JWT, perfiles dev / pre / prod.
¿Qué tipos SQL soportáis?+
La gama estándar completa de PostgreSQL: arrays, enums, JSONB, UUID, la familia de fecha/hora (date, time, timestamptz), precisión numérica y decimal, binario (bytea), validación de longitud varchar/char, claves compuestas y foráneas, más herencia de tablas y particiones declarativas. Y la generación nunca falla ante un tipo que no reconozca: cae a un valor seguro por defecto (string) que tu equipo puede afinar después, así que siempre obtienes un backend arrancando. Señalamos cualquier columna así juntos en el kick-off, sin sorpresas. Por eso el proceso es guiado.
Para agencias
El schema es de mi cliente.+
Podemos trabajar desde un schema anonimizado/renombrado (estructura sin nombres reales) o bajo NDA tripartito. No se ofrece on-premise: la fábrica nunca sale.
¿Crece con el proyecto?+
Sí. Los módulos nuevos se generan como vertical slices independientes y se añaden junto a tu código, sin tocar lo que tu equipo ya construyó.
¿Misma arquitectura en todos los proyectos?+
Sí. El output determinista da la misma estructura siempre, así que los devs rotan entre proyectos sin curva de entrada.
¿Listo para verlo sobre tu schema?
Agenda una llamada →Tu schema es confidencial. NDA a petición.
Precio por proyecto, calculado sobre tu schema. Lo ves funcionando antes de pagar, y el primer pago es una señal, no el proyecto entero. La misma capa estructural, con un equipo interno, son meses.