← Proyectos

App a medida · 2026

Planificación de producción

Carpintería industrial. Por privacidad de la empresa no se muestran capturas reales de la aplicación.

Sustituye las hojas de pedido y los partes de horas en papel. Tres motores de planificación propios, contención de máquinas y trazabilidad por pedido.

El problema

La oficina planificaba con hojas de cálculo y los partes de horas del taller llegaban en papel. Tres consecuencias.

  • Ninguna verdad única sobre la planta

    Saber qué máquina estaba libre y cuándo entraba un pedido dependía de la cabeza del planificador.

  • El círculo no se cerraba

    Las horas reales del taller no se comparaban nunca con las estimadas en oficina.

  • Cero trazabilidad

    Ningún registro de quién cambió qué ni cuándo, en pedidos que pasan por seis o siete fases y varias semanas.

El proceso

  1. Fase 1

    Entender el taller

    Conversaciones con quien planifica de verdad. De ahí salieron las reglas raras, que no estaban en el plan inicial.

  2. Fase 2

    Modelar el dominio

    Pedido → producto → artículo → fase. Primero el esquema, después la interfaz.

  3. Fase 3

    Los motores

    Tres planificadores en TypeScript puro, sin React ni Prisma delante, con sus tests.

  4. Fase 4

    Interfaz y rebrand

    Sistema de tokens, paleta del Gantt validada y una sola tipografía en varios pesos.

  5. Fase 5

    Producción

    Despliegue y evolución con el taller usándolo.

Tres planificadores, no uno

Se implantó una aplicación donde la oficina planifica y el taller ficha: las hojas de cálculo y los partes en papel pasan a ser una sola fuente que los dos miran.

Planificar no es una sola pregunta, así que no hay un solo planificador sino tres, cada uno para una forma distinta de mirar la misma planta.

El de abajo es una versión reducida de dos de ellos, ejecutándose aquí mismo. Las barras no están dibujadas: se calculan.

7 días · 3 más por la cola de máquinas

Una fila por máquina

Corte

CNC

Canteado

Montaje

Cada máquina hace un pedido a la vez. Pulsa una referencia para subirla al principio de la cola y mira cómo empuja a las demás: eso es la contención, y es la diferencia entre una planificación y un deseo.

El modelo

El encargo traía una condición por delante de todo: hacía falta una base de datos robusta. Un pedido pasa por seis o siete fases y varias semanas, y lo que se guarda mal en marzo se paga en junio.

Fue el mayor reto del proyecto y es la parte que mejor ha aguantado: el modelo ha absorbido reglas nuevas —tipos de producto, rutas, plantillas— sin migraciones traumáticas ni datos huérfanos.

Lo que se ve abajo es su forma, no su diseño.

Pedido
Producto
Artículo
  • detalle polimórficosegún el tipo de producto
  • materiales
  • operaciones y horas por fase
El esquema habla el idioma del taller, no el de la base de datos. Todo lo demás —formularios, Gantt, informes— salió casi solo de aquí.

Las reglas que complican el problema

Un Gantt de manual encadena fases y ya está. Estas cuatro salieron del negocio real, y son exactamente el tipo de lógica que se rompe en silencio al tocarla. Por eso vive en funciones puras con tests.

  • Fases de tipo FECHA

    Las esperas de proveedor no compiten por máquina: corren en paralelo entre pedidos y actúan como hito de calendario.

  • Solape de horas

    Una fase puede adelantarse un número configurable de horas respecto al fin de la anterior.

  • Inicio forzado y arrastre

    El arrastre manual solo puede retrasar; el inicio forzado manda en ambos sentidos. Sobre los dos, la máquina siempre gana.

  • Fases completadas a 0 h

    Transparentes al planificador: aparecen como hechas y no reservan recurso. Arriba, con una fase a cero entre medias; abajo, sin ella. El plazo es el mismo.

El proyecto en cifras

  • 3motores de planificación
  • 70tests unitarios
  • 26modelos y enums
  • 6.000líneas en 67 archivos
  • 112commits
  • 3meses, y sigue

Qué me llevo

  • Modelar el dominio antes que la interfaz

    El acierto fue que el esquema hablara el idioma del taller. Formularios, Gantt e informes salieron casi solos de ahí.

  • La lógica difícil se aísla y se testea

    Los tres planificadores no saben nada de React ni de Prisma. Es la única razón por la que se pudo iterar sobre las reglas de precedencia sin miedo.

  • Las reglas raras son el producto

    El solape, las esperas de proveedor y los inicios forzados no estaban en el plan: salieron de hablar con quien planifica. Son también lo que hace que la herramienta se use.

  • Autorización en el servidor, sin excepciones

    Ocultar un botón no es seguridad. Cada acción mutante lo comprueba por su cuenta.

¿Y en tu caso?

¿Hay algo en tu negocio que hoy viva en hojas de cálculo y en papel?

Esto se hizo para una carpintería industrial, pero el problema de fondo —la información repartida y nadie con la foto completa— se parece mucho de un oficio a otro. Cojo proyectos freelance compatibilizándolos con mi trabajo, y si me lo cuentas te digo con franqueza si te puedo ayudar.

Cuéntame tu caso →