Práctica Desarrollo de App en Producción | Antuan Jury S.A.

¿Quieres que tu práctica se note en un sistema que ya está en producción? Únete a Antuan Jury S.A.
En Antuan Jury S.A. llevamos más de 70 años vistiendo a las empresas de Chile. Hace un año dejamos de gestionar el tallaje de uniformes con planillas y WhatsApp: hoy tenemos un sistema propio, en producción, que ya toma tallas, genera órdenes de producción y emite etiquetas.

Ahora buscamos a quien lo lleve al siguiente nivel. No es un proyecto de escritorio ni una maqueta: es software real, con usuarios reales, corriendo todos los días.

El sistema que vas a intervenir
Una aplicación web que resuelve el ciclo completo del tallaje corporativo:

Portal del colaborador: cada trabajador entra con su RUT, elige sus tallas del catálogo de su empresa y firma digitalmente.
Panel administrativo: carga masiva de colaboradores, catálogos de prendas, sistemas de tallaje (alfabético, numérico, calzado, personalizado), lotes de producción y estados de entrega.
Salidas a producción: Excel consolidado, resumen de orden en PDF y etiquetas térmicas.
Stack real: React 19 + Vite + TypeScript + Tailwind en el frontend. Express + TypeScript + SQLite en el backend. WebSockets para sincronización en vivo. Autenticación JWT con roles. Desplegado en Docker sobre VPS propio.

Cómo trabajamos: Spec-Driven Development
Este es el corazón de la práctica y lo que la hace distinta.

No vas a recibir tickets vagos ni a improvisar sobre el código. Vas a trabajar con desarrollo dirigido por especificaciones: la especificación es el artefacto principal, y el código es su consecuencia.

El ciclo que vas a dominar:

Especificar — Un documento que describe qué debe pasar y por qué, en lenguaje de negocio y sin decidir tecnología. Con criterios de aceptación verificables y las preguntas abiertas marcadas explícitamente.
Planificar — Recién ahí, el cómo: arquitectura, contratos de API, modelo de datos, y las restricciones reales del proyecto (SQLite, Docker, el código que ya existe).
Descomponer — Tareas pequeñas, cada una con una condición de "listo" que se puede comprobar.
Implementar con IA — Usarás asistentes de codificación (Claude Code, Cursor, GitHub Spec Kit) alimentados por esa especificación. Cuando el contexto está bien escrito, la IA deja de alucinar y empieza a construir.
Verificar contra la spec — No contra la impresión de que "se ve bien". Contra el criterio que escribiste antes de programar.
Por qué importa: la mayoría de los desarrolladores junior usa IA para escribir código más rápido. Los que destacan la usan para construir lo correcto. La diferencia está en la especificación, y eso es exactamente lo que vas a practicar aquí.

Tus desafíos concretos
Estos no son ejercicios inventados. Son las brechas reales del sistema, priorizadas.

🛡️ Construir la red de seguridad. Hoy cada cambio se valida a mano. Vas a especificar el comportamiento esperado de las piezas críticas —cálculo de tallas, consolidación de lotes, generación de exportables— y levantar la suite de pruebas automatizadas que lo protege. Es el trabajo que habilita todo lo demás.

📱 Unificar la experiencia móvil. El tallaje se toma de pie, en una planta, con un teléfono en la mano. Hoy conviven dos árboles de componentes móviles en paralelo. Vas a especificar la experiencia objetivo y ejecutar la unificación, respaldado por las pruebas del punto anterior.

📡 Resolver la toma en terreno sin conexión. Las bodegas y plantas de nuestros clientes tienen mala señal. ¿Qué pasa si se corta la red a mitad de una encuesta ya firmada? Hoy no hay respuesta. Tú vas a definirla y a implementarla.

📊 Dar visibilidad a la gerencia. Un panel que responda sin pedirle nada a nadie: qué empresas van atrasadas, qué colaboradores faltan por responder, qué lotes están listos para producción. Con alertas automáticas en vez de correos de seguimiento.

🧠 Importación inteligente de nóminas. Las listas de colaboradores llegan en decenas de formatos distintos, cada cliente con el suyo. Vas a prototipar un paso de normalización asistido por IA que interprete la planilla, proponga el mapeo de columnas y lo deje listo para revisión humana.

Qué te llevas de esta práctica
Un método que te va a servir toda tu carrera. Spec-Driven Development es cómo se está construyendo software serio con IA en 2026. Lo vas a aplicar, no a leer sobre él.
Experiencia sobre código en producción, con usuarios que se quejan si algo se rompe. Eso enseña más que cualquier proyecto de curso.
El ciclo completo: especificación, desarrollo, pruebas, despliegue en Docker y monitoreo de lo que subiste.
Uso profesional de IA para desarrollo, que es distinto de pedirle código a un chat: gestión de contexto, verificación y criterio para saber cuándo la IA se equivocó.
Un portafolio demostrable. Al terminar, vas a poder mostrar las especificaciones que escribiste y las funcionalidades que salieron de ellas.
A quién buscamos
Estudiante de último año de Ingeniería en Informática, Programación, Analista Programador o carrera afín de la Escuela de Informática del Duoc UC.
Base sólida en desarrollo web: JavaScript o TypeScript, algo de React, nociones de API REST y bases de datos relacionales. No necesitas dominar nuestro stack; necesitas poder aprenderlo rápido.
Capacidad de escribir con claridad. En esta práctica vas a redactar tanto como vas a programar. Si te cuesta explicar por escrito lo que hace tu código, este rol te va a costar.
Criterio propio frente a la IA. Que la uses es esperable. Que sepas cuándo desconfiar de ella es lo que buscamos.
Autonomía. Preguntas cuando corresponde, investigas cuando puedes, propones antes de que te pidan.
Condiciones
Modalidad: oficinas en Viña del Mar / Hibrido eventualmente.
Horario: Jornada completa, conversable según tu carga académica.
Remuneración: Práctica remunerada, acorde al mercado.
Duración: A convenir según tu plan de estudios.
Mentoría directa con gerencia y con el equipo que construyó el sistema.

Cómo postular
La postulación tiene dos archivos. Nada más. Léelo completo antes de escribir, porque acá está la mitad del trabajo hecho.

1. Tu CV
En PDF. Una o dos páginas. Si tienes GitHub, portafolio o algún proyecto en línea, incluye el enlace.

2. Una "mini especificación" de una página
Esta es la parte importante y la que la mayoría no sabe cómo abordar. Así que te la explicamos completa.

El encargo: imagina el sistema que describimos más arriba —el que toma las tallas de los trabajadores de una empresa y arma las órdenes de producción—. Elige una sola funcionalidad que tú le agregarías y descríbela.

Reglas:

Máximo una página. Si te sobra espacio, mejor.
Nada de código. Ni una línea. Tampoco elijas tecnologías, ni menciones frameworks, ni dibujes la base de datos. No es lo que estamos evaluando.
Una sola funcionalidad. No un plan completo del sistema. Una cosa, bien pensada.
Formato libre: PDF, Word, Google Docs o Markdown. Nos da igual cómo se vea.
Responde estas cuatro preguntas, en este orden:

¿Qué problema resuelve? Describe la situación molesta que existe hoy. Una persona pierde tiempo, se equivoca, o no se entera de algo a tiempo. Sé específico sobre el problema, no sobre tu solución.
¿Para quién? Nombra a la persona concreta que se beneficia: el trabajador que elige su talla, la persona de administración que carga las listas, el jefe de producción, la gerencia. Explica en qué momento de su día usaría esto.
¿Qué debería pasar? Cuenta el paso a paso de la funcionalidad, como si se lo explicaras a alguien que no es programador. Incluye qué pasa cuando algo sale mal: el usuario se equivoca, se corta internet, el dato viene incompleto.
¿Cómo sabríamos que quedó bien? Aquí es donde se separan las buenas postulaciones de las demás. Escribe entre 3 y 5 frases que se puedan comprobar con un sí o un no. "Que sea rápido" no sirve, porque nadie puede verificarlo. "Que el trabajador termine de elegir sus tallas en menos de 2 minutos" sí sirve, porque se puede medir.
Un ejemplo del tono que buscamos, sobre una funcionalidad distinta a propósito, para que no copies:

Problema: cuando un trabajador se equivoca de talla, avisa por WhatsApp a su jefatura, que reenvía el mensaje a administración, que lo corrige a mano. A veces la orden ya se envió a producción y el uniforme se fabrica mal.

Para quién: el trabajador, que hoy no tiene forma de corregirse solo; y administración, que recibe estas correcciones por canales informales.

Qué debería pasar: el trabajador puede volver a entrar con su RUT y cambiar sus tallas mientras la encuesta de su empresa siga abierta. Si ya se cerró, el sistema le muestra a quién contactar en vez de dejarlo sin salida.

Cómo sabríamos que quedó bien: (1) el trabajador puede modificar sus tallas sin ayuda de nadie; (2) el cambio queda registrado con fecha y hora; (3) si la encuesta está cerrada, el sistema no permite el cambio y explica por qué; (4) administración puede ver qué respuestas fueron modificadas después de la primera vez.

Qué evaluamos: que hayas entendido un problema real y que hayas sabido definir cuándo está resuelto. Nada más. No importa si tu idea ya existe en el sistema, si es simple, o si un experto la haría distinto. Una funcionalidad chica bien especificada vale mucho más que una ambiciosa mal explicada.

Qué no evaluamos: ortografía perfecta, formato bonito, extensión, ni conocimiento previo de nuestro rubro.

Enviar
📩 a.jury@antuan.cl

Asunto exacto: Práctica SDD 2026 – [Tu nombre completo]

Plazo: Septiembre

Te confirmamos la recepción por correo. Si tu postulación avanza, te citamos a una conversación donde vamos a revisar tu especificación contigo: nos interesa cómo llegaste a ella, no defenderla ni corregirla.

Si tienes dudas sobre el encargo, escríbenos y pregunta. Preguntar cuando algo no está claro es exactamente lo que hace este trabajo.