Los manuales de IKEA animados (y cómo montar el tuyo con Bygga)

El suelo del salón lleno de paneles. Una bolsa de espigas. Una llave Allen que ya tienes repetida en tres cajones. Y en la página 7 un muñequito sin cara que te mira como si fuera obvio que la pieza C va al revés.

Montar un mueble de IKEA es un proceso. Uno con piezas, herramientas, un orden concreto y un par de pasos donde, si te equivocas, toca desatornillar media hora de trabajo.

¿Te suena de algo más? A mí me suena a desplegar a producción, a dar de alta a alguien nuevo en el equipo o a preparar una release los viernes (no lo hagas).

Bygga es una web de código abierto que convierte cualquier caja de IKEA en una guía de montaje animada en 3D, dibujada como el manual de papel y leída en voz alta. Gratis, sin cuenta y con licencia MIT. Y si abres el repo te encuentras una arquitectura que sirve para explicar cualquier proceso paso a paso, no solo un KALLAX.

En este post vas a ver:

• Qué hace Bygga y por qué no guarda ni un solo PDF de IKEA.
• Cómo está montado el código: catálogo, generador paramétrico, motor de dibujo, voz e IA.
• Por qué la IA solo aparece en los bordes, y con la clave de cada visitante.
• Cómo puedes reutilizar ese patrón para explicar los procesos y flujos de trabajo de tu equipo.
• Qué limitaciones tiene y qué conviene saber antes de clonarlo.

¿Qué es Bygga y qué hace exactamente? ¶

Bygga es una aplicación web que te guía para montar muebles de IKEA. Escribes el nombre o el número de artículo de la caja y sigues cada paso en 3D, con un dibujo a línea que imita el manual de papel y una voz que te lee las instrucciones. Su README lo resume así: “Type the name or article number on an IKEA box and follow every assembly step in 3D, drawn like the paper manual and read out loud.”

La hacen Hassan El Mghari (conocido en GitHub como Nutlope) y Youssef, con Together AI detrás. El código está en github.com/Nutlope/bygga y la web en usebygga.com.

Unas cifras para situarte, sacadas del README a 29 de octubre de 2026:

• 1.171 productos de IKEA en el catálogo, con 2.180 medidas distintas, de las gamas de Reino Unido y Estados Unidos.
• 1.476 clips de voz pregrabados que suenan sin clave y sin gastar tokens.
• 283 escuchas grabadas que se repiten como test cada vez que alguien toca la parte de voz.
• Todo bajo licencia MIT.

Para que lo veas con algo concreto, cogí la guía del KALLAX 2x2. La ficha dice 77 x 39 x 77 cm, 40 minutos, una persona y nivel fácil. Son 7 paneles y 30 herrajes en 11 pasos, y te pide destornillador y martillo.

La guía tiene cuatro pestañas: herramientas, piezas, montaje y hecho. En herramientas cada una trae su apaño por si te falta (“el nivel lo hace una app del móvil”, “unas tijeras sirven” en vez del cúter). En piezas te dibuja cómo extender los paneles en el suelo para que los cuentes antes de empezar. Y en cada paso tienes repetir, pausa, un botón “Slow” y un contador de minutos restantes.

Galería · 2 imágenes

La guía del KALLAX 2x2 en Bygga

Ampliar

1 / 2 · Paso 1, con lupa y voz

1Paso 1, con lupa y voz 2Las piezas, contadas

Siempre hay un aviso a la vista: “Hands full? Turn on voice”. Si lo activas, dices “next” con las manos ocupadas sujetando la balda y la guía avanza sola.

🔑 Bygga no está afiliada con IKEA. El fichero NOTICE del repo lo deja claro: IKEA y los nombres de sus productos son marcas de Inter IKEA Systems B.V., y la licencia MIT no da ningún derecho sobre ellas.

¿Cómo genera Bygga una guía sin copiar ni un PDF de IKEA? ¶

Bygga no guarda los manuales de IKEA. Cada guía la genera su propio código a partir de los datos públicos del producto (nombre, tipo, medidas) y de un generador que sabe cómo se monta cada tipo de mueble.

Lo dicen en el README sin rodeos: “We don’t mirror IKEA’s PDF manuals, on purpose. Every guide is generated, and each cover links to the official manual on ikea.com.”

Y en el AGENTS.md del repo, que son las reglas que leen los agentes de IA que trabajan en el proyecto, está la versión todavía más estricta:

Every guide is generated by src/lib/plan and follows the product’s IKEA assembly manual: the same steps in the same order, with the same parts, fittings and counts. Draw and word everything ourselves; IKEA’s drawings, photos and text are copyrighted, so never copy them into the app.

Los pasos, el orden y las piezas son los del manual oficial, pero el dibujo y las palabras son suyos. Por eso la web te avisa al empezar de que la contrastes con el manual de papel de la caja.

Esa decisión parece legal, pero cambia la arquitectura entera. Si no puedes copiar el PDF, tienes que describir el mueble como datos y escribir el código que convierte esos datos en pasos y dibujos. Y en cuanto tienes eso, ya no dependes de un PDF por producto: tienes un generador.

El flujo completo tiene cinco piezas:

1. Catálogo (scripts/ikea): unos scripts leen los listados públicos de IKEA y generan filas compactas en src/data. Los datos en bruto no se suben a git, solo las filas ya construidas.
2. Especificación (ProductSpec): cada producto es un objeto con nombre, medidas en centímetros, tipo de mueble y parámetros.
3. Generador (src/lib/plan): convierte esa especificación en un Plan con piezas, herrajes, pasos y herramientas.
4. Consumidores del plan: el motor de dibujo, la voz, la vista para imprimir, las tarjetas para compartir y el service worker.
5. IA en los bordes: solo para lo que el código no puede resolver solo, y con la clave de quien la usa.

Ahora vamos pieza a pieza, que para eso hemos abierto la caja.

Curso en vídeo

Tu propio AGENTS.md, como el de Bygga, para que el agente respete las reglas de la casa

En la lección 3 escribimos el AGENTS.md de un proyecto real regla a regla, y te llevas la plantilla para el tuyo.

Entra en el curso gratis →

¿Qué datos describen un mueble en Bygga? ¶

Un mueble en Bygga es un ProductSpec: un objeto con nombre, variante, tipo (archetype), medidas, minutos, personas, dificultad y un bloque de parámetros según el tipo. Todo está tipado en src/lib/types.ts.

El catálogo se guarda en un formato muy compacto. Este es el arranque real de src/data/ikea-rows.ts, que el propio fichero marca como generado:

// Generated by scripts/ikea/build.ts from IKEA product data. Do not edit by hand.// Rows we can draw, one per line: name|kind|variant|w|h|d|params|keywords|slugexport const IKEA_ROWS = `AGAM|junior|Junior chair|43|91|52||kids childrenAGEN|armchair|Armchair with cushion|58|79|56|seatH=45,sdp=40ALEX|chest|Drawer unit on castors, 36 × 50 cm|36|50|45|rows=4,knobs=none...`;

Una línea por producto, separada por barras verticales. Nada de JSON inflado. De esa fila sale un ProductSpec con sus parámetros. Para una estantería, por ejemplo, los parámetros son columnas, filas, baldas, si lleva trasera, si va colgada de la pared o el grosor de los paneles en milímetros.

Hay ocho tipos de mueble: shelf, drawers, table, bed, cabinet, seat, sofa y custom. El último es el interesante para nosotros, porque es el más genérico. Un mueble custom se describe con dos listas: piezas y pasos.

export interface CustomStep {  title: string;  detail?: string;  add?: string[]; // piezas que entran en este paso  fix?: CustomFix[]; // herrajes que se usan  tools?: ToolId[]; // llave Allen, destornillador, taladro...  people?: 1 | 2; // ¿hace falta otra persona?  warnings?: WarnId[]; // "dos personas", "fíjalo a la pared"...  repeat?: number; // "haz esto dos veces"  check?: "square"; // comprueba que está en escuadra}export interface CustomParams {  parts: CustomPart[];  steps: CustomStep[];}

Quédate con esta estructura. Un paso tiene un título, un detalle, lo que entra, lo que necesitas, cuánta gente hace falta y qué puede salir mal. Más adelante la vamos a usar para algo que no es un mueble.

¿Cómo funciona el generador paramétrico de src/lib/plan? ¶

El generador recibe un ProductSpec y devuelve un Plan. Primero busca si la familia del producto (la primera palabra del nombre: KALLAX, MALM, BILLY) tiene una receta escrita a partir de su manual. Si no la tiene, tira del generador de su tipo de mueble.

Esta es la puerta de entrada, en src/lib/plan/index.ts:

function buildOne(b: PlanBuilder, spec: ProductSpec) {  // primero, una familia que sabe cómo se monta de verdad  if (buildFamily(b, spec)) return;  // si no, el generador de su tipo  switch (spec.archetype) {    case "shelf":      return buildShelf(b, spec);    case "drawers":      return buildDrawers(b, spec);    case "table":      return buildTable(b, spec);    // bed, cabinet, seat, sofa, custom...  }}

Una familia puede hacer dos cosas, según src/lib/plan/families/family.ts: devolver una receta (recipe, que produce un CustomParams con piezas y pasos) o dibujar la guía ella misma (build). Si no cubre ese producto concreto, devuelve null y el sistema cae al generador genérico. Un comentario del código explica que una familia a medio escribir no rompe nada: el sistema se la salta.

Los generadores por tipo son código paramétrico puro. Mira un paso real de src/lib/plan/shelf.ts, el de la barra para colgar ropa de una estantería OMAR:

b.step(  {    title: "Fit the clothes rail",    detail: "Screw the holders to the sides under the top shelf, then drop the rail in.",    tools: ["screwdriver"],    kind: "screws",  },  () => {    // coloca los tornillos en cada lateral, a la altura calculada    b.fits(HW.screwS, f.sides.map(/* posición y dirección de cada tornillo */), 0.1);    b.then(0.1);    // la barra entra desde abajo y hacia delante    b.add(rail, [0, -180, 260]);  },);

El paso tiene dos mitades. Arriba, lo que se dice (título, detalle, herramientas, tipo de paso). Abajo, lo que se ve: qué herraje entra, por dónde, con qué retardo y desde dónde llega cada pieza. El PlanBuilder (src/lib/plan/builder.ts) va apuntando cada pieza, cada agujero y cada tornillo con su posición en milímetros y su dirección.

Las piezas se etiquetan solas con letras (ABCDEFGHJKLMNPRSTUVWXYZ, sin I ni O para no confundirlas con números) y los herrajes salen de una tabla con medidas reales: espiga de 8 x 30 mm, tornillo Allen de 7 x 34 mm, y así hasta más de treinta tipos.

¿Y cuánto código es esto? El README habla de unas 10.000 líneas en 46 archivos. Lo conté en el clon del 29 de octubre: 45 ficheros y 10.036 líneas en la raíz de src/lib/plan. Y aparte, la carpeta families con 463 ficheros, uno o varios por familia de IKEA. Es la parte gorda del proyecto, y tiene sentido: ahí vive todo el conocimiento de cómo se monta cada cosa.

💡 El conocimiento caro (cómo se monta un MALM) está en código revisable y testeable, no en un prompt. La IA no decide en qué orden van las piezas.

¿Cómo dibuja los pasos en 3D como si fueran de papel? ¶

El motor de dibujo vive en src/engine y usa three.js. Para que parezca un manual impreso y no un videojuego, el equipo tomó tres decisiones:

• Cámara ortográfica (THREE.OrthographicCamera en src/engine/stage.ts): sin perspectiva, igual que los dibujos técnicos.
• Contornos a línea: cada pieza saca sus aristas con EdgesGeometry y las pinta con LineSegments2 (src/engine/drawable.ts), que permite trazos con grosor real.
• Una segunda cámara para la lupa: el círculo que amplía el tornillo es otra cámara ortográfica pequeña con su propio render.

La web tiene una sección, “The paper manual, explained”, que enseña lado a lado el estilo folleto y el estilo Bygga del mismo paso. La diferencia es clara: mismo encuadre, mismas piezas, pero con flechas gruesas, piezas resaltadas en color y la lupa con el gesto exacto.

Todo esto funciona offline: el dibujo se calcula en el navegador a partir del plan. No hay vídeos pregrabados por producto ni imágenes por paso. El mismo motor dibuja también las tarjetas para compartir (scripts/og/render.mjs) y la vista para imprimir en A4 (/build/<mueble>/print).

¿Por qué la voz de Bygga no gasta tokens? ¶

Porque está grabada de antemano. En public/voice hay 1.476 clips generados una sola vez con el modelo de voz Kokoro. La app los encadena en el orden que toca y no llama a ninguna API para leerte un paso.

El diseño está explicado en el comentario de cabecera de src/lib/voice/script.ts:

/** * What the hands-free voice says. Every line is one clip: the recorder renders * each unique line once, and the app plays them back to back. Keep lines short * and self-contained so they can be reused across products. */export const LINES = {  on: "Voice is on. I'll read each step out loud.",  sayNext: "When you're done, just say next.",  halfway: "You're halfway there.",  last: "Last step.",  two: "This one's easier with two people.",  // ...} as const;

Lo importante es “short and self-contained so they can be reused across products”. Si cada frase es corta y no depende del mueble, la misma grabación de “Last step” sirve para 1.171 productos. Es lo mismo que haces cuando extraes un componente: lo que se repite, se reutiliza.

La parte de escuchar sí usa IA: Whisper en Together oye lo que dices por un micrófono con cancelación de eco (/api/listen). Pero lo que convierte ese texto en una orden no es un modelo. Es una función con listas de frases, en src/lib/voice/commands.ts:

/** * Turns what the mic heard into an intent. Only short, whole phrases count as * commands, so talking to a friend ("hold the back panel") never moves a step. */const PHRASES: Record<Kind, string[]> = {  next: ["next", "next step", "done", "im done", "keep going", "whats next" /* ... */],  back: ["back", "go back", "previous", "undo" /* ... */],  slower: ["slower", "slow down", "too fast" /* ... */],  // ...};

Si le dices a tu pareja “sujeta la trasera”, la guía no avanza. Solo cuentan frases cortas y completas. Las muletillas (“um”, “okay”, “please”) se quitan solo de los extremos, así que “okay next please” es “next”.

Para no romper esto, el repo trae npm run voice:check, que repite 283 escuchas grabadas y comprueba que cada una sigue dando la intención correcta. Es un test de regresión para la voz, y está en el README como paso obligatorio después de tocarla.

¿Dónde usa Bygga la IA y por qué con tu propia clave? ¶

Bygga usa IA en tres sitios concretos, y todos funcionan con la clave de Together AI de cada visitante, que pegas en un modal (src/components/KeyModal.tsx). Sin clave, la web sigue funcionando: catálogo, dibujos, voz grabada y modo sin cobertura.

Los tres usos son:

1. Oír “siguiente” con Whisper, como acabas de ver.
2. Borradores de productos que no están en el catálogo: la ruta /api/guide primero busca en el catálogo; si no encuentra nada y tienes clave, pide a un modelo que proponga un ProductSpec, lo valida con zod (src/lib/spec.ts) y, si el modelo cae en un producto que ya conocen, prefiere la ficha revisada del catálogo. Sin clave, te deja elegir la forma del mueble a mano.
3. Un chat de ayuda que responde con dibujos de tu propia guía.

Ese tercer punto es el que más me gusta. El prompt de sistema de src/app/api/help/route.ts le dice al modelo que puede añadir etiquetas al final de su respuesta: [part B] enseña el panel B, [fitting 3] el herraje 3 y [step 5] el dibujo del paso 5. Como mucho tres. El modelo no dibuja nada: señala dibujos que el motor ya sabe hacer.

They see pictures from their own guide when you add tags: [part B] shows panel B,[fitting 3] shows fitting 3, [step 5] shows the drawing of step 5 [...]At most 3, together on the last line. Never mention the tags or the pictures in words.

También le pide respuestas de tres frases como máximo, que si algo puede hacer daño lo diga primero y que, si falta una pieza, te recuerde que las tiendas de IKEA suelen reponer herrajes pequeños gratis. Y limita las peticiones: 20 por IP para la ayuda, fotos de menos de 3 MB.

Los modelos están en src/lib/together.ts como listas con fallback configurables por variable de entorno: si el primero no está disponible, prueba el siguiente. Hay listas separadas para texto, visión, lectura de manuales y planificación. Y la función chat rechaza cualquier llamada sin clave: el comentario dice que la clave de la persona es la única que hay.

⚠️ “Gratis” vale para la web y la voz grabada. Las partes con IA (oír “siguiente”, el chat y la búsqueda por foto) gastan de tu cuenta de Together AI.

Es el patrón de “trae tu propia clave” (BYOK): el usuario pone el coste de la IA y el proyecto pone el producto. Así una web gratuita con IA no arruina a quien la mantiene.

Construye agentes con criterio

Decide qué capa de tu producto lleva IA y cuál se queda en código de siempre

Verás los seis niveles de arquitectura de un agente, de las tools y los guardarraíles a la orquestación, con código y evals para que no se descontrole en producción.

Entrar a la masterclass →

6 niveles de arquitectura, en directo · Con Web Reactiva Premium

¿Cómo sigue funcionando sin cobertura? ¶

Con un service worker en public/sw.js. El comentario de cabecera explica para qué: “Keeps guides working with a bad signal (garages, basements, new flats)”. Trasteros, sótanos y pisos recién entregados sin wifi. Justo donde montas muebles.

Cada tipo de recurso tiene su estrategia:

Como el dibujo se genera en el navegador y la voz son ficheros estáticos, una guía que ya abriste funciona entera sin conexión. Lo único que pierdes son las partes con IA.

¿Cómo puedes usar el patrón de Bygga para explicar los procesos de tu equipo? ¶

Esto es lo que me hizo abrir el repo. Si quitas los muebles, Bygga es esto: un formato de datos para describir un proceso, un generador que lo convierte en pasos, y una interfaz que los presenta uno a uno, con lo que necesitas, quién tiene que estar y qué puede salir mal.

Eso le falta a la página de Confluence que explica cómo se despliega tu proyecto.

La traducción es casi directa:

¿Qué procesos tienen sentido? Los que cumplen tres condiciones: se repiten, tienen un orden que importa y equivocarse cuesta. Unos cuantos ejemplos:

• Onboarding de alguien nuevo: accesos, clonar repos, levantar el entorno local, primer PR.
• Despliegue a producción cuando todavía hay pasos manuales.
• Release de una app móvil: versiones, capturas, notas, revisión de tiendas.
• Rotación de un secreto que toca varios servicios.
• Respuesta a un incidente: el runbook que nadie lee hasta que es tarde.

Olvídate del 3D. Lo que te llevas es que el proceso pasa a ser datos revisables en un PR, y la presentación (paso a paso, con requisitos y avisos) sale de un generador. Si mañana cambia un paso, cambias una línea y todas las vistas se actualizan: la guía interactiva, la versión para imprimir y lo que lea el asistente.

Si quieres dibujar además la arquitectura que hay detrás de cada proceso, te encaja la skill de la que hablé en diagram-design, la skill que dibuja tu arquitectura.

¿Cómo adaptar Bygga a un proceso de tu equipo paso a paso? ¶

La forma práctica es no reescribir Bygga, sino quedarte con sus ideas y su interfaz de pasos, y cambiar el modelo de datos. Este es el camino que yo seguiría.

1. Clónalo y ejecútalo tal cual ¶

git clone https://github.com/Nutlope/bygga.git && cd bygga && npm install

npm run dev

Abre http://localhost:3000, escribe BISSA y monta un mueble entero. Prueba también /build/malm-3-drawers?step=12 para saltar a un paso y /build/malm-3-drawers/print para la vista imprimible. Antes de adaptar nada, entiende qué se siente al usarlo.

2. Lee el AGENTS.md antes de tocar nada ¶

El proyecto usa Next.js 16, y el propio AGENTS.md avisa de que tiene cambios incompatibles con lo que un modelo puede haber aprendido. Pide leer la guía que viene en node_modules/next/dist/docs/ antes de escribir código. Si vas a trabajar con un agente, esto le ahorra muchos errores. Si quieres entender bien para qué sirve ese fichero, lo conté en para qué sirve AGENTS.md.

3. Define tu propio tipo de “paso” ¶

Inspírate en CustomStep y cambia las piezas por lo que manejas tú. Un ejemplo para un despliegue:

// Herramientas y avisos de tu equipo, igual que ToolId y WarnId en Byggaexport type ToolId = "github" | "vpn" | "vercel" | "1password" | "grafana";export type WarnId = "prod" | "irreversible" | "pair" | "freeze";export interface ProcessStep {  title: string;  detail?: string;  uses?: string[]; // artefactos que entran en juego: rama, build, entorno  tools?: ToolId[];  people?: 1 | 2; // 2 = hazlo con alguien de plataforma  warnings?: WarnId[];  check?: string; // cómo sabes que ha ido bien  minutes: number;}export interface ProcessSpec {  name: string;  owner: string;  steps: ProcessStep[];}

4. Escribe la receta de tu proceso como datos ¶

Esto es el equivalente a una familia de muebles con su recipe. Un fichero por proceso, revisable en un PR:

import type { ProcessSpec } from "../types";export const deploy: ProcessSpec = {  name: "Despliegue a producción",  owner: "equipo-plataforma",  steps: [    {      title: "Comprueba que main está en verde",      tools: ["github"],      check: "Todos los checks del último commit pasan",      minutes: 2,    },    {      title: "Ejecuta las migraciones en staging",      detail: "Revisa que no bloquean tablas grandes.",      tools: ["vpn"],      warnings: ["irreversible"],      minutes: 10,    },    {      title: "Promociona el build a producción",      tools: ["vercel"],      people: 2,      warnings: ["prod"],      check: "El health check responde 200 durante 5 minutos",      minutes: 5,    },  ],};

5. Reutiliza la interfaz de pasos y cambia el dibujo ¶

La interfaz de la guía (src/components/guide/GuideApp.tsx, unas 1.170 líneas) ya resuelve lo difícil: pestañas de requisitos, paso a paso con anterior y siguiente, repetir, pausa, minutos restantes y avisos. El motor 3D de src/engine está pensado para muebles y no te sirve para un despliegue. Cámbialo por lo que tenga sentido en tu caso: una captura anotada, un diagrama SVG del sistema con el servicio afectado resaltado o un fragmento de terminal.

6. Copia las tres ideas que hacen que funcione ¶

• Voz pregrabada (opcional): si tus pasos tienen frases cortas y reutilizables, puedes grabarlas una vez y no gastar nada al leerlas.
• Asistente que señala, no que inventa: copia el truco de [step 5]. Pasa al modelo el proceso entero como contexto y deja que responda con etiquetas que tu interfaz convierte en el paso exacto. El conocimiento sigue en tus datos.
• Service worker si el proceso se hace en sitios sin red (un CPD, una planta, un almacén).

7. Pídeselo a tu agente con contexto ¶

Si trabajas con Claude Code, OpenCode o Codex, este prompt es un buen arranque:

Estás en un fork de Bygga (Next.js 16, lee AGENTS.md y la guía de
node_modules/next/dist/docs/ antes de escribir código).

Quiero reutilizar la guía paso a paso para procesos internos de mi equipo,
no para muebles.

1. Crea src/lib/process/types.ts con ProcessStep y ProcessSpec
   (inspirados en CustomStep de src/lib/types.ts).
2. Crea una receta de ejemplo en src/lib/process/recipes/deploy.ts.
3. Crea la ruta /process/[slug] que reutilice la estructura de
   src/components/guide/GuideApp.tsx: pestañas de requisitos (herramientas
   y accesos), pasos con anterior/siguiente, minutos restantes y avisos.
4. No uses src/engine: en lugar del dibujo 3D, muestra el detalle del paso
   y su comprobación.
5. No toques el catálogo de IKEA ni las rutas de /api.

Antes de escribir código, enséñame el plan y los ficheros que vas a tocar.

Pedirle el plan antes de tocar nada importa más de lo que parece. Si quieres afinar esa forma de trabajar, en subagentes para programar con IA tienes prompts para repartir este tipo de tareas.

¿Qué diferencia hay entre una wiki y una guía al estilo Bygga? ¶

La wiki cuenta el proceso. La guía al estilo Bygga te acompaña mientras lo haces. No es lo mismo leer cómo se despliega que desplegar con alguien al lado diciéndote qué toca ahora.

No todo merece este tratamiento. Un proceso que haces una vez al año con dos pasos se queda en la wiki. Uno que hace gente nueva cada mes, con quince pasos y tres sitios donde romper algo, sí.

¿Qué limitaciones tiene Bygga? ¶

Bygga es un proyecto joven y lo dice su propia hoja de ruta. Esto es lo que conviene saber:

• La voz solo está en inglés. Llevarla a más idiomas está en el README como tarea pendiente.
• Faltan formas raras: estanterías de tres esquinas, combinaciones de esquina y anchos de PAX que no se dividen en módulos. Están listadas en scripts/ikea/skips.ts.
• El escáner de manuales está apagado detrás de la variable NEXT_PUBLIC_SCAN=1, a la espera de probarlo con manuales reales.
• Las partes con IA necesitan tu clave de Together AI y gastan de tu cuenta.
• Hay que contrastar con el manual de papel. La guía es generada y la propia web te lo avisa.
• Las cifras cambian: 1.171 productos, 1.476 clips y 283 escuchas son del README del 29 de octubre de 2026.
• El motor 3D es muy específico. Si quieres reutilizar el proyecto para otra cosa, lo aprovechable es la arquitectura y la interfaz de pasos, no src/engine.

Y un detalle de casa que me hizo gracia: el AGENTS.md prohíbe los guiones largos en cualquier parte, copy, código, comentarios y commits. El chat de ayuda llega a sustituirlos por comas al vuelo cuando el modelo los cuela. Cada equipo tiene sus manías.

Preguntas frecuentes sobre Bygga ¶

¿Qué es Bygga? ¶

Bygga es una aplicación web gratuita y de código abierto que convierte cajas de IKEA en guías de montaje animadas en 3D, dibujadas como el manual de papel y leídas en voz alta. La crearon Hassan El Mghari (Nutlope) y Youssef, con Together AI.

¿Bygga es oficial de IKEA? ¶

No. Bygga es un proyecto independiente y no está afiliado con IKEA. Los nombres de producto son marcas de Inter IKEA Systems B.V. y la licencia MIT del código no da derechos sobre ellas.

¿Bygga copia los manuales de IKEA? ¶

No. No guarda los PDF de IKEA a propósito. Cada guía la genera su código a partir de los datos públicos del producto, siguiendo los pasos del manual oficial pero con dibujos y textos propios, y cada portada enlaza al manual en ikea.com.

¿Cuántos muebles tiene Bygga? ¶

Según el README de octubre de 2026, 1.171 productos con 2.180 medidas distintas, de las gamas de Reino Unido y Estados Unidos. Para productos que no están, puede generar un borrador con IA si pones tu clave de Together AI.

¿Bygga es gratis? ¶

La web, el catálogo, los dibujos y la voz grabada son gratis y sin cuenta. Las funciones con IA (oír “siguiente”, el chat de ayuda y la búsqueda por foto) usan tu propia clave de Together AI y consumen de tu cuenta.

¿Con qué tecnología está hecho Bygga? ¶

Con Next.js 16 (App Router y Cache Components), React 19, TypeScript, CSS plano con Motion y sin kit de UI. Usa three.js para dibujar los pasos, zod para validar especificaciones y Together AI para las partes con IA.

¿Cómo genera Bygga los pasos de montaje? ¶

Con un generador paramétrico en src/lib/plan. Primero busca una receta escrita para la familia del producto (KALLAX, MALM, BILLY); si no la hay, usa el generador de su tipo de mueble. El resultado es un plan con piezas, herrajes, pasos y herramientas.

¿Funciona Bygga sin conexión? ¶

Sí, para guías que ya hayas abierto. Un service worker guarda las páginas, los ficheros de la app y los clips de voz, y el dibujo se calcula en el navegador. Las funciones con IA sí necesitan red.

¿En qué idiomas habla Bygga? ¶

De momento solo en inglés. Añadir más idiomas a la voz está en la hoja de ruta del proyecto.

¿Puedo usar el código de Bygga para mis propios procesos? ¶

Sí, el código tiene licencia MIT. Lo más aprovechable es la arquitectura (proceso descrito como datos, generador y guía paso a paso) y la interfaz de pasos. El motor 3D está pensado para muebles, así que para procesos de software conviene sustituirlo por capturas o diagramas.

TL;DR ¶

• 🪑 Bygga convierte 1.171 productos de IKEA en guías animadas en 3D, con voz y sin cuenta, y su código es abierto con licencia MIT.
• 📐 No copia ni un PDF: describe cada mueble como datos y un generador paramétrico en src/lib/plan produce piezas, herrajes y pasos.
• 🔊 La voz son 1.476 clips pregrabados: leerte un paso no gasta tokens, y la IA solo entra para oír “next”, chatear o buscar por foto, con tu clave.
• 🧭 El chat de ayuda no dibuja: señala piezas y pasos de tu guía con etiquetas como [step 5], un patrón que puedes copiar para tus asistentes.
• 🛠️ Si cambias muebles por despliegues u onboardings, tienes una forma de explicar los procesos de tu equipo como datos revisables en un PR.

Fuentes ¶

• Bygga, la web
• Guía del KALLAX 2x2 en Bygga
• Repositorio Nutlope/bygga en GitHub (README, AGENTS.md, NOTICE y código fuente consultados el 29 de octubre de 2026)
• Documentación de three.js: EdgesGeometry
• Together AI

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter