Camino al Autodesk App Store: de herramienta interna a producto

VaultPilot funciona. Lo desarrollamos junto a Avant Leap, es el primer agente de IA nativo para Autodesk Vault Professional 2026, y hoy vive en tres superficies: un panel de chat dentro del cliente de Vault, un comando en AutoCAD y un add-in de Inventor. Con eso podría darme por satisfecho. Pero el objetivo siempre fue otro: que cualquier empresa pueda instalarlo desde el Autodesk App Store, y ese camino está resultando ser un segundo proyecto completo.

Lo cuento porque casi nadie lo cuenta. Las publicaciones sobre add-ins suelen terminar en la demo: la herramienta funcionando en la máquina de su creador, con su configuración, sus rutas y sus permisos. Entre esa demo y un producto listado hay una distancia que se mide en detalles aburridos.

El instalador es el primer examen

Una herramienta interna puede permitirse asumir cosas: que cierta carpeta existe, que el usuario es administrador, que la versión de Vault es la que hay en la oficina. Un producto no asume nada. El instalador tiene que funcionar en una máquina que nunca has visto, con políticas de seguridad que no controlas, y tiene que poder desinstalarse sin dejar rastro. Escribir esa lógica lleva más tiempo del que cuesta admitir.

Lo mismo pasa con la compatibilidad. En casa, "funciona con Vault 2026" es una frase. En el App Store es una declaración formal por versión de producto, y cada versión nueva de Vault o de Inventor reabre la pregunta. Mantener un add-in comercial es comprometerse con un calendario de actualizaciones que no defines tú, sino Autodesk con cada release.

Documentar para desconocidos

La documentación interna puede ser un mensaje de chat: "instala esto y me escribes si algo falla". La de un producto tiene que funcionar sin el autor cerca. Un desconocido, en otro huso horario, con otro idioma, tiene que poder instalar, configurar y resolver los errores típicos sin escribirte. Cada pregunta que te llega por correo es una página de documentación que faltó.

Y detrás de eso viene lo que nadie asocia con el software: un canal de soporte definido, una política de actualizaciones, un proceso para reportar problemas. Cosas de producto, no de código.

La revisión existe por una buena razón

El App Store tiene un proceso de revisión, y me parece bien que lo tenga. Es el mismo principio que aplico en mis propios agentes: la compuerta se construye antes que la confianza. Un marketplace sin filtro se llena de herramientas que asumen demasiado, documentan poco y desaparecen al primer cambio de versión. Pasar esa revisión no es un trámite: es la prueba de que la herramienta deja de depender de su creador.

Nada de esto es glamuroso. Y exactamente por eso lo estoy documentando en público: porque la distancia entre herramienta y producto es donde se decide si algo sirve a diez personas o a un mercado. Si estás construyendo tu propio add-in, o quieres uno a medida para tu equipo, hablemos: el camino es más corto cuando alguien ya lo recorrió.