Foundation: por qué construir sobre una base existente es 3-5x más rápido que empezar de cero

Cada proyecto de software empieza igual: hay que configurar autenticación, base de datos, colas, CORS, logs, deployments. Semanas de trabajo antes de escribir una sola línea de lógica de negocio. Esto es lo que hace el desarrollo tradicional: empezar de cero cada vez.

En SOM-OS no empezamos de cero. Empezamos de sistema. Se llama Foundation y es la base sobre la que construimos cada proyecto. Te explico cómo funciona y por qué reduce los tiempos de entrega de 3 meses a 3 semanas.

El problema del desarrollo desde cero

Un proyecto nuevo típico pierde las primeras 2-4 semanas en infraestructura:

• JWT, roles, refresh tokens, rate limiting
• Swagger docs
• Uploads a S3 con presigned URLs
• Websockets para tiempo real
• Emails transaccionales
• Colas con Redis + BullMQ
• Migrations, Docker, CI/CD

Todo necesario. Ninguna de estas cosas es lo que el cliente te contrató para hacer. El cliente te contrató para construir su CRM, su sistema de captación, su panel de gestión. Pero el desarrollo tradicional te obliga a configurar BullMQ antes de poder escribir la primera regla de negocio.

El resultado: proyectos que tardan 3 meses cuando podrían tardar 3 semanas. No porque el equipo sea lento — porque empieza desde cero cada vez.

Qué es Foundation

Foundation es un monorepo template con un stack completo:

• Nuxt 4 (frontend)
• NestJS 11 (backend)
• PostgreSQL 17 (base de datos)
• Redis (caché + colas)
• BullMQ (queue manager)
• Stripe (pagos)
• LangChain (IA)

Todo configurado. Todo conectado. Todo siguiendo el mismo patrón.

Módulos pre-construidos

20+ módulos que ya funcionan y no hay que escribir:

1. Autenticación y autorización — JWT, refresh tokens, roles, permisos
2. Colas de tareas — BullMQ + Redis para jobs asíncronos
3. Pagos — Stripe con webhooks, subscriptions y one-time payments
4. Uploads — S3 con presigned URLs
5. Emails transaccionales — templates HTML, cola, reintentos
6. Websockets — tiempo real sin configurar Socket.io desde cero
7. Rate limiting — throttler de NestJS configurado
8. Swagger — OpenAPI auto-generado desde los DTOs
9. IA — LangChain integrado en el backend, no como bolt-on

Generación de código con Hygen

No escribimos boilerplate a mano. Generamos entidades, servicios y controladores con Hygen. Un comando genera toda la estructura de un módulo nuevo:

pnpm hygen module new --name customer --fields "name:string,email:string,plan:string"

Esto genera: entity, DTO (create + update + patch), service, controller, module, spec file. Todos siguen el mismo patrón. Todos usan los mismos path aliases. Todos validan con Zod.

Validación con Zod

Toda validación es Zod, en frontend y backend. Un schema, dos usos:

// shared/schemas/customer.ts
import { z } from 'zod'

export const customerSchema = z.object({
  name: z.string().min(2),
  email: z.string().email(),
  plan: z.enum(['free', 'pro', 'enterprise']),
})

export type Customer = z.infer<typeof customerSchema>

El frontend valida antes de enviar. El backend valida al recibir. Un solo source of truth. Sin class-validator en backend y Yup en frontend. Sin desincronización.

Velocidad 3-5x: de dónde viene

La velocidad no viene de escribir código más rápido. Viene de no escribir código que ya existe.

Cuando empezamos un proyecto sobre Foundation:

• Semana 1: Lógica de negocio. Ya hay auth, ya hay base de datos, ya hay colas. Solo añadimos entidades y reglas.
• Semana 2: Integraciones. Cal.com, Stripe, APIs externas. Los patrones ya están definidos.
• Semana 3: IA y deployment. LangChain ya está en el backend. Solo configuramos el agente.

Caso real: Sando Capital

Sando Capital es un intermediario financiero en Mallorca. No tenía web, ni sistema, ni base de datos. Los leads llegaban por WhatsApp.

En 3 semanas le construimos:

• Web a medida con un único CTA
• Agendado automático con Cal.com
• Agente IA que cualifica leads antes de la llamada
• Base de datos centralizada + panel CRM

-70% tiempo calificando leads. 100% leads en base de datos. 0 conversaciones perdidas en WhatsApp.

Esto no fue velocidad por velocidad. Fue velocidad porque no construimos lo que ya estaba construido. Puedes leer el caso completo en el post original del blog de SOM-OS.

IA desde el día uno

La diferencia más grande entre Foundation y un proyecto desde cero es la IA. En un proyecto tradicional, la IA se añade al final como un bolt-on: un chatbot pegado con cinta que lee de una API separada.

En Foundation, LangChain está integrado en el backend desde el principio:

// modules/ai/agents/lead-qualifier.agent.ts
import { Injectable, Logger } from '@nestjs/common'
import { ChatOpenAI } from '@langchain/openai'
import { PromptTemplate } from '@langchain/core/prompts'
import { StructuredOutputParser } from '@langchain/core/output_parsers'

@Injectable()
export class LeadQualifierAgent {
  private readonly logger = new Logger(LeadQualifierAgent.name)

  private model = new ChatOpenAI({
    modelName: 'gpt-4o-mini',
    temperature: 0.3,
  })

  async qualify(leadData: Record<string, unknown>) {
    const parser = StructuredOutputParser.fromNamesAndDescriptions({
      qualifies: 'boolean: does this lead qualify?',
      product: 'suggested product or null',
      reason: 'brief reason for the decision',
    })

    const prompt = PromptTemplate.fromTemplate(
      'Analyze this lead: {lead}\n\n{format}'
    )

    const chain = prompt.pipe(this.model).pipe(parser)
    const result = await chain.invoke({
      lead: JSON.stringify(leadData),
      format: parser.getFormatInstructions(),
    })

    this.logger.log(`Lead qualified: ${JSON.stringify(result)}`)
    return result
  }
}

El agente lee y escribe en la misma base de datos. Tiene acceso a las mismas colas, los mismos eventos, el mismo contexto. No es un add-on — es parte de la arquitectura.

Cero decisiones arbitrarias

Uno de los problemas menos visibles del desarrollo desde cero son las decisiones arbitrarias. Cada desarrollador elige:

• ¿ORM o query builder? → Prisma ya está configurado
• ¿Zod o class-validator? → Zod en todas partes
• ¿Tailwind o CSS modules? → Tailwind + UI kit compartido
• ¿BullMQ o Agenda? → BullMQ + Redis ya funcionando
• ¿JWT o session? → JWT con refresh tokens ya implementado

Cada decisión ya está tomada — y está tomada bien, porque se ha probado en proyectos reales. Solo adaptas. Esto significa que cualquier desarrollador que entre al proyecto entiende el código en horas, no en semanas.

Conclusión

El tiempo que un equipo pasa configurando auth y colas es tiempo que no pasa en lógica de negocio. Foundation elimina ese coste. No es un template — es un sistema con 20+ módulos pre-construidos, patrones definidos y IA integrada desde el día uno.

No empiezas de cero. Empiezas de sistema. Y eso cambia todo.

Si quieres ver cómo aplicamos esto en sistemas reales, échale un vistazo a SOM-OS — construimos sistemas operativos de negocio con IA en Mallorca. También puedes explorar nuestro mapa del caos, la auditoría que hacemos antes de escribir una sola línea de código.