Mi primer plugin de WordPress no nació para venderse: ¿debería convertirlo en producto?

Mi primer plugin para WordPress tiene una característica poco habitual: no está pensado para distribuirse. Lo uso yo. Su función es concreta: optimizar imágenes con Python y utilizar OpenAI para proponer textos alternativos y elementos relacionados con el SEO.

La pregunta aparece después, casi inevitablemente: si la herramienta resuelve un problema real en mi propio flujo de trabajo, ¿merece la pena intentar monetizarla? ¿O estamos entrando en una etapa en la que este tipo de automatizaciones dejan de ser productos diferenciados y pasan a convertirse en una capa más de cualquier sistema editorial?

El punto de partida: una herramienta interna, no un producto

Construir algo para uso propio cambia las prioridades. No necesito diseñar un onboarding, documentar cada opción ni asegurar compatibilidad con todas las combinaciones posibles de WordPress. Puedo optimizar el flujo para mis contenidos, mis convenciones de nombres y mi manera de revisar imágenes.

Ese contexto también reduce el coste de tomar decisiones provisionales. El plugin puede resolver únicamente los casos que encuentro en mi día a día: recibir una imagen, procesarla, generar una versión más adecuada para la web y preparar metadatos que después puedo aceptar, corregir o descartar.

La diferencia entre esa herramienta y un producto comercial no está necesariamente en la cantidad de código. Está en todo lo que aparece alrededor: instalación, permisos, gestión de errores, límites de uso, privacidad, actualizaciones, soporte y capacidad para sobrevivir a entornos que no controlo.

La arquitectura obliga a separar dos problemas

WordPress utiliza plugins escritos en PHP, mientras que mi procesamiento de imágenes se apoya en Python. Por tanto, el plugin no debería entenderse como un único bloque, sino como una integración entre WordPress y una pieza de procesamiento externa o separada. La documentación de la comunidad de WordPress describe los plugins como extensiones desarrolladas en PHP e integradas con el CMS.

Esta separación puede ser razonable para un prototipo personal, pero se vuelve crítica si el proyecto se abre a terceros. Habría que definir cómo se ejecuta Python, cómo se controlan los tiempos de espera, qué ocurre si una imagen no puede procesarse y dónde se almacenan los originales y las versiones optimizadas.

También convendría evitar que la generación automática se convierta en una operación irreversible. Un flujo sólido debería conservar el archivo original, registrar qué transformación se ha aplicado y permitir repetir o deshacer el proceso. La optimización no consiste únicamente en reducir peso: también puede afectar a dimensiones, formato, metadatos incrustados y calidad visual.

Alt y SEO: generar propuestas no equivale a publicar sin revisar

La parte más visible del proyecto es la generación de textos alternativos mediante un modelo con capacidad para analizar imágenes. La API de OpenAI permite enviar imágenes como entrada para extraer información y describir elementos visuales, algo que encaja técnicamente con este flujo.

Pero el resultado no debería tratarse como verdad editorial. Un texto alternativo describe la función o el contenido relevante de una imagen dentro de una página concreta. La recomendación de Google es utilizar descripciones útiles y contextuales, evitar el keyword stuffing y tener en cuenta que el atributo alt también es una cuestión de accesibilidad, no solo de posicionamiento.

Por eso, el plugin debería presentar el texto generado como una propuesta. La revisión humana sigue siendo importante para detectar errores de identificación, matices que no aparecen en la imagen o descripciones que no corresponden al propósito de la página.

La misma cautela se aplica al SEO. Una descripción generada puede ayudar a preparar títulos, nombres de archivo o metadescripciones, pero no garantiza una mejora en buscadores. Google explica que los fragmentos de resultados se generan principalmente a partir del contenido de la página y que puede utilizar la metadescripción cuando la considera más adecuada. Automatizar ese campo no equivale, por sí solo, a optimizar la página.

El coste oculto no es el código: son las responsabilidades

Mientras el plugin es solo mío, puedo aceptar ciertos riesgos operativos. Si lo convierto en servicio, tendría que resolverlos de forma explícita. El primero es la privacidad: las imágenes podrían contener personas, documentos, información comercial o datos que no deberían enviarse a un proveedor externo.

La documentación de privacidad de WordPress recomienda identificar qué datos se comparten con terceros, con qué finalidad se almacenan, durante cuánto tiempo y qué controles existen para reducirlos o eliminarlos. En el caso de la API de OpenAI, los datos de clientes de la API no se utilizan por defecto para entrenar o mejorar los modelos, aunque siguen existiendo condiciones de tratamiento, registros operativos y responsabilidades por parte de quien envía los datos.

También tendría que proteger las claves de API. Nunca deberían quedar expuestas en el navegador ni distribuirse dentro del plugin de forma que cualquier usuario pueda reutilizarlas. Si la herramienta fuese comercial, probablemente tendría más sentido centralizar el acceso mediante un servicio propio o permitir que cada cliente configurase sus credenciales.

La distribución introduce además cuestiones de licencia y revisión. WordPress.org exige que el código incluido en su directorio sea compatible con la GPL o una licencia compatible. Sus directrices permiten cobrar por servicios externos, pero no por bloquear arbitrariamente funcionalidades dentro de un plugin que se presenta como gratuito. Esto condiciona la forma de plantear una posible versión pública.

¿Hay que monetizarlo?

Mi conclusión provisional es que todavía no intentaría vender el plugin como “automatización de imágenes con IA”. Esa descripción es demasiado amplia y fácil de replicar. La existencia de modelos accesibles reduce el valor de una integración genérica: comprimir una imagen o pedir una descripción alternativa ya no constituye necesariamente una ventaja defendible.

La oportunidad estaría en el flujo completo. Por ejemplo, en resolver de forma fiable un proceso editorial específico: detectar imágenes pendientes, aplicar unas reglas de optimización, generar propuestas coherentes con el tipo de contenido, mantener trazabilidad y permitir una revisión rápida dentro de WordPress.

Antes de convertirlo en producto, mediría tres señales:

si el flujo ahorra tiempo de forma recurrente y no solo en una prueba puntual;
si otras personas tienen el mismo problema con restricciones parecidas;
si estarían dispuestas a pagar por la fiabilidad, la integración y el soporte, no simplemente por una llamada a un modelo.

Eso apunta a un cambio de paradigma, aunque no necesariamente a la desaparición del software especializado. El código aislado puede perder valor como producto; el criterio, la integración y la responsabilidad operativa pueden ganarlo.

Por ahora, mi plugin cumple una función más importante que generar ingresos: me permite entender dónde está el verdadero problema. Si después de usarlo descubro que la parte difícil no es llamar a OpenAI, sino diseñar un proceso seguro y útil dentro de WordPress, quizá ahí sí exista un producto. La siguiente pregunta no es “¿puedo venderlo?”, sino “¿qué problema concreto seguiría resolviendo aunque mañana cambiase el modelo?”