El marco PODA

Introducción

Este mes me han pasado 3 cosas

1. He visto este video de Tina Huang, una científica de datos que crea contenido sobre IA en youtube:
   • https://youtu.be/kKG5MDF_234?si=9MFmon9sQuNX7VLW&t=168
   • En el vídeo habla del concepto de “hiperspecific Apps”: usar la IA para crear software para un uso muy específico, tanto personal como profesional, que nunca existiría como software comercial.
2. He empezado a ver publicaciones en LinkedIn de personas que están creando su propio software, no dynamos para Revit, ni macros para excel, SOFTWARE. Algunos ejemplos aleatorios de mi feed:
   • https://www.linkedin.com/posts/luiscarlosrevitbimmanager_openbim-bim-ia-activity-7440948552480157697-d5x4
   • https://www.linkedin.com/posts/diana-aguilar-jim%C3%A9nez-b1854017a_plugin-en-claude-cowork-activity-7436487064008806401-wXjo
   • https://www.linkedin.com/posts/silvertq_openbim-construccion40-qaqc-activity-7442958215816032256-koxh
   • Este lo tienes que ver si o si, de Ivan Caamaño Souto https://www.linkedin.com/posts/ivancaamanosouto_presupuestos-en-5-minutos-con-ia-del-chat-activity-7444476831581306880-AIXV
3. He creado mi propio Visor IFC con un motor gráfico creado desde cero, que funciona rápido y sin parpadeos con modelos medianos, y una interfaz web con todas las herramientas básicas: federación, cortes, medidas, propiedades, etc.
   • En 3 horas y sin tener ni idea de programar.
   • Con Google Antigravity y mis licencias de pago de Gemini y Claude.

¿De dónde sale todo esto?

Llevamos un par de años hablando de que la IA cambiaría totalmente el mundo de la programación, incluso han ido apareciendo nuevos paradigmas como:

• el “vibe coding”: crear software hablándole a un chat de IA como https://lovable.dev/
• o el Spec-Driven Development (https://github.com/github/spec-kit): Desarrollo Guiado por Especificaciones (SDD) un enfoque de desarrollo de software que consiste en definir muy bien lo que quieres y la IA se encarga de escribir el código. Si quieres cambiar algo, modificas la definición y el código como si se tiene que escribir entero de cero, lo hace la IA.

Y hasta hace poco, todo esto servía para hacer webs chulas, prototipos de interfaz y apps “de juguete” que fallaban bastante.

Pero a finales de noviembre de 2025 salió Claude Opus 4.5, una semana después de Gemini 3 Pro, y una semana antes de ChatGPT 5.2, Y luego en febrero, todos ellos han sacado nuevas versiones (Opus 4.6, Gemini 3.1, ChatGPT 5.4). Estos modelos de IA han dado un salto importante en capacidad de programación y AHORA SÍ, podemos empezar a hacer software “de verdad” (sencillo en cuanto a arquitectura de software y nulo en ciberseguridad) como un Visor IFC completo.

Entramos de lleno en la era del post-usuario

El post-usuario es un usuario que ya no se limita a consumir software, sino que lo construye. No es programador, no tiene formación técnica en desarrollo, pero ha dejado de esperar a que alguien le resuelva el problema. Abre un IDE con IA, describe lo que necesita, itera, y en una tarde tiene funcionando una herramienta que hace exactamente lo que ningún SaaS del mercado cubría. Y cuando esa herramienta deja de servirle, la descarta sin pestañear y construye otra.

El concepto no es del todo nuevo. La industria lleva años hablando del citizen developer, ese usuario empoderado para crear soluciones dentro de plataformas low-code y no-code como Microsoft Power Apps. Pero había una diferencia fundamental: el citizen developer construía dentro de un jardín vallado, con los bloques que un plataforma le permitía usar. El post-usuario no pide permiso. No necesita plataforma, no necesita licencia enterprise, no necesita que IT le abra un entorno. Tiene un problema, tiene acceso a una IA, y ya.

No todo el mundo sirve para ser un post-usuario, pero si en tu oficina eres el encargado de crear los excels complejos, el que prueba cientos de plugins de Revit, o acabas montando los tableros de Notion o Trello para organizar al resto del equipo, tienes todas las papeletas para evolucionar a “post-usuario”.

Pero… un gran poder conlleva… criterio

Que la IA te permita crear aplicaciones funcionales sin saber programar, usando solo tu experiencia, ¿significa realmente que debas hacerlo? ¿te merece la pena el coste de oportunidad? ¿estás asumiendo riesgos operativos?

Por otro lado, si tu negocio es crear productos de software (ya sea un SaaS B2B, una plataforma a medida o una micro-herramienta), debes hacerte una pregunta incómoda: ¿tienes entre manos un negocio que realmente justifique cobrar por él? ¿aportas un valor que tu cliente no podría replicar con IA?

Personalmente, ahora estoy en ese segundo grupo: trabajo en Hiberus (la mayor tecnológica privada española) y gran parte de mi día a día consiste en idear soluciones de software para clientes concretos o para sectores enteros. Pero desde hace unos meses, antes de liarme a dibujar flujos, diseñar interfaces o sentarme con mi jefa a hablar de costes y modelos de negocio, tengo que parar en seco y analizar si mi idea aporta un valor por el que el cliente esté dispuesto a pagar. Y para ayudarme he creado un marco de decisión.

La gran mayoría de los que lean esto no serán desarrolladores profesionales, pero comparto este marco igualmente porque sirve exactamente igual para hacerte la pregunta inversa: como cliente ¿debería pagar por esto, o creármelo yo mismo con IA?

El marco PODA

Concepto

He diseñado este marco en torno al concepto de APORTACIÓN DE VALOR de un software, porque da igual quién lo cree o si usa IA o no para ello. Si aporta valor suficiente merecerá la pena pagar por ello.

Además, centrar el análisis en la aportación de valor en lugar de en temas más técnicos, le da al marco cierta durabilidad ante el rápido avance de la IA. Cosas como el efecto red o depuración de responsabilidades, no están relacionados con la capacidad de desarrollo (ni de humanos ni de IAs), la IA mejorará, pero a medio plazo:

• Conocimiento:  Gran parte del conocimiento sectorial es tácito (no está documentado, sólo está en la cabeza de especialistas). La IA no puede aprender lo que no existe en ningún sitio al que pueda acceder.
• Efecto red: La IA no puede fabricar comunidades de usuarios activos, inventar datos históricos que requieren masa crítica, ni obligar a todo un sector a adoptar un “lenguaje común” o formato cerrado para colaborar.
• Arquitectura IT: la IA será capaz de generar sistemas complejos, pero sin un humano verificador, no habrá forma de distinguir una arquitectura IT sólida de una que parece sólida.
• Operación: La IA hará mantenimiento preventivo y corrección de errores, pero cuando algo sale mal y hay consecuencias legales o financieras, alguien tiene que responder. Y ese alguien tiene que ser una persona física o jurídica, no un algoritmo.

Mecánica del marco

Puedes enfocarlo de estas dos maneras:

• ¿Tiene mi software el Peso suficiente en Operación, Dominio y Arquitectura para sobrevivir comercialmente a la IA?
• Para resolver mi necesidad, ¿la solución tiene el Peso suficiente en Operación, Dominio y Arquitectura como para que pague por ella en lugar de crearla yo mismo con IA?

El marco PODA es válido tanto para evaluar una idea nueva de software (producto, proyecto, SaaS, etc) como para cuestionar la supervivencia de uno existente. Plantea cuatro preguntas: dos en Dominio (Conocimiento y efecto red), una en Arquitectura IT y una en Operación.

La regla es simple: para que una propuesta aporte valor real en tiempos de IA, necesitas responder SÍ a como mínimo una de las cuatro preguntas. Cuantas más respuestas afirmativas, más valor no reemplazable por IA (más “peso”) tiene la solución frente a la alternativa de hacérselo uno mismo. Si todas las respuestas son un NO, lo que hay sobre la mesa es un prompt, no un producto.

Dominio

1. Conocimiento: ¿Incorpora conocimiento que el usuario no sabe que necesita, que no está disponible de forma estructurada (en el cliente o públicamente), y que requiere años de experiencia sectorial para definirlo correctamente?
   • Posiblemente la pregunta más importante porque con la IA puedes crear software pero ¿sabes cómo debería funcionar?
     • Un programa de facturación para estudios de arquitectura puede ser sencillo a nivel “informático” pero incorpora lógicas como que tipo de impuesto se debe aplicar si el proveedor está en Canarias y el cliente en Italia.
       • A tu asesor contable no le pagas por los modelos que te presenta en hacienda, le pagas por el conocimiento que tiene para hacerlo bien. Pues con el SW lo mismo.
     • Un software de cálculo estructural, puede ser más complejo en cuanto a código, pero además requiere de un conocimiento profundo en cuanto a matemáticas, física y normativa de construcción.
     • Por el contrario: un visor IFC, un exportador de planos a PDF, o un extractor de albaranes, no necesitan conocimientos profundos.
2. Efecto red: ¿Aporta valor porque conecta a una red de usuarios, acumula datos colectivos que un usuario aislado no puede generar solo, o porque funciona como estándar de facto en la colaboración profesional del sector?
   • Existen tres tipos de efecto red, que se diferencian en el mecanismo (personas, datos o formato), pero la estructura es idéntica: un usuario aislado con IA puede clonar la herramienta, pero no puede clonar lo que emerge del colectivo.
     • Efecto de red directo: más usuarios = más valor para cada uno. Por ejemplo un marketplace o red social. Crear con IA tu propio LinkedIn, o tu propio Nalanda (antiguo Obralia) no tiene valor sin los usuarios.
     • Efecto de red por datos: el software contiene muchos datos compartidos por terceros y esos datos mejoran el producto para todos. Bases de precios, google maps, una plataforma de objetos BIM públicos… con IA puedes replicar la herramienta, pero no sus datos.
     • Efecto de red por compatibilidad: el valor crece porque más gente usa el mismo estándar, formato o convención, el estándar de facto. ¿Sería útil que te crearas tu propio Excel, Revit o Presto? ¿Cómo colaborarías con terceros? ¿a base de formatos abiertos y ya?
       • Paradójicamente, los formatos abiertos son una solución a este efecto red y sin embargo, este efecto red es de los más fuertes, y los formatos abiertos, poco usados.
       • Pero ojo, dentro de este efecto red también se incluye que el software cuente con una masa crítica de usuarios que lo conocen y dominan (aunque no colaboren entre ellos), por ejemplo: Presto, aunque uses el formato BC3, el 75% de las personas que hacen presupuestos, saben hacerlos con Presto, y la mayoría no tienen intención de aprender a hacer presupuestos con otro software. Lo mismo para Revit, Excel, AutoCad, Photoshop…

Arquitectura

3. ¿Requiere expertos IT altamente especializados, para al menos, verificarla?
   • Puedes crear tu propio CDE pero…:
     • ¿tienes garantías de que la IA tiene controlada la edición simultánea del mismo archivo?
     • ¿la plataforma es cibersegura?
     • ¿Aguanta si se conectan 100 usuarios a la vez?
     • ¿Quieres conectarlo con un ERP pero su API no es pública y necesitas del fabricante para ello?
   • La IA evoluciona muy rápido, y puede (o podrá en cuestión de meses) hacer un CDE complejo, o un CRM especializado en promotoras inmobiliarias, pero por muy ciberseguro que sea el código, por muy buena que sea su arquitectura IT, si la persona que lo crea con la IA, no es experta en ciberseguridad o en arquitecturas IT, no podrá verificar que el trabajo de la IA es bueno, deberá confiar en la IA.
     • Pero si tienes un hackeo y los datos de todos tus proyectos, o los datos de los clientes de la promotora, se roban, la confianza en la IA no sirve de nada.
     • Necesitas un profesional experto que “al menos, verifique” el código y pagarle para que si algo falla puedas pedirle responsabilidades a alguien de verdad.

Operación

4. ¿Aporta valor al entrar en producción?
   • Una vez el software se empieza a usar, ¿requiere mantenimiento y actualizaciones? y ¿Cómo de grave sería que fallara? Cruzando estas dos variables (mantenimiento y fallo) tenemos 4 escenarios en los que un software comercial aporta distintos grados de valor:
     • Un gestor de tareas o un visor BIM, tienen poco mantenimiento y no pasa nada grave si fallan.
     • Un software de nóminas o uno de cálculo estructural, tienen poco mantenimiento, pero si fallan la pueden liar parda.
     • La web corporativa, se actualiza constantemente, pero si falla no pasa nada.
     • Un ERP para constructoras, requiere mantenimiento continuo y si falla puede ser grave.
   • La respuesta a esta pregunta sigue siendo binaria (Sí/No). Sólo hay un No rotundo, pero cada uno de los 3 “Sí” te dice porque el SW comercial aporta valor real.

Bonus: contexto del cliente

Es raro contestar a las 4 preguntas con un No, pero si se diera el caso, todavía tienes dos grandes motivos para seguir comprando el software (y eres cliente) o seguir teniendo un producto que se vende bien (si eres desarrollador profesional):

• El cliente no sabe IA, no por lo menos al nivel que hace falta para crear software.
  • Algunos dirán que este punto es muy débil, que lo bueno de la IA es que le puedes pedir las cosas en lenguaje natural, etc.
    • Hay gente que lleva trabajando 15 años, 3 horas al día con excel, y no sabe lo que es una tabla dinámica. Algunos no saben la diferencia entre una tabla normal y un rango.
    • Ha tenido que venir una pandemia mundial, para que la gente aprendiera a tener reuniones online.
    • Solo el 4.5% de los “trabajadores del conocimiento” tiene acceso a una IA de pago (https://majestic-piroshki-ae4249.netlify.app/) Sólo el 1% está usando la IA para crear software.
  • Da igual lo fácil que sea la IA, la gran mayoría no tiene interés ni paciencia para meterse en esto. Una PYME que cuente con 1 “post-usuario” es muy afortunada.
  • Ojo: lo que si es un riesgo para el software comercial, es la explosión de competencia (de pago y gratuita) que van a aparecer. Pero este marco no es para hacer un DAFO respecto a la competencia, sino el cambio de aportación de valor en la era de la IA.
• Coste de oportunidad: El cliente sabe IA, pero dedicar su tiempo al negocio, vale más que el coste de la licencia, suscripción, o lo que sea.
  • Los milenials no dejamos de usar E-mule y BitTorrent porque nos hayamos concienciado de los derechos de autor, sino porque Spotify y Netflix son absurdamente cómodos, y nos ahorran horas de gestión descargando música y series.
  • Ojo de nuevo: lo que si puede pasar es que si el único valor que aporta un software es el ahorro de tiempo de creártelo tu mismo, el software deberá percibirse como muy barato.

Reflexiones finales

En 2026 entramos en una era de revolución absoluta en lo que entendemos por software. Hoy ser un post-usuario es una opción real para aplicaciones sencillas. En cuestión de meses lo será para aplicaciones más complejas, y probablemente, antes de que acabe el año, no tendremos límites técnicos para crear lo que queramos.

Cuidado, que nadie crea que en diciembre de 2026 va a poder decirle a chatgpt “hazme un Revit” y funcionará. Pero con sistemas de IAs y métodos específicos, como el SDD, y un par de meses, sí que lo podrá conseguir.

El marco PODA te ayuda a señalar, cómo usuario, todo el dinero en licencias y suscripciones que te podrías ahorrar si dieras el paso hacia un post-usuario. Y no sólo ahorro de dinero, también cubrir una necesidad que nadie te está resolviendo, ni aunque quieras pagar.

Pero debemos aprovechar esta revolución con criterio. El software comercial y los desarrollos profesionales a medida van a seguir existiendo, en tanto en cuanto sigan aportando valor. El marco PODA te ayuda, como fabricante/desarrollador profesional, a entender dónde queda el valor que un post-usuario con IA no puede remplazar (buenas prácticas de nicho, efectos de red, garantía, confianza….). Tendremos más oferta, más calidad, y mejores precios, pero el mercado seguirá existiendo.

Y si eres fabricante/desarrollador, distribuidor o incluso formador de un software que ha conseguido pocos o ningún “Sí” en el marco PODA:

• A corto plazo no vas a notar una bajada de ingresos, gracias a los que no saben IA y al coste de oportunidad. Aprovecha este tiempo para darle más valor en dominio, arquitectura IT y Operación a tu software.
• A medio plazo (2-4 años) vas a tener mucha más competencia, prepárate para que puedas elegir si quieres competir en calidad y/o precio, y no verte obligado a sólo lo segundo.
• Como formador/consultor de un software específico que no haga caso de los dos puntos anteriores, piensa que tu superpoder es dominar la tecnología y saber explicarla.
  • La IA es un multiplicador, de lo bueno y de lo malo, y en una sociedad “analfabeta digital”, la IA va a crear más diferencias entre los que saben y los que no, y por lo tanto, también va a crear más oportunidades para los que forman.
• A largo plazo, creo que el software comercial seguirá dos caminos:
  • Plataforma base que te resuelve y te da garantías en cuanto a arquitectura IT complejas y Operación crítica, y pensadas para ser personalizadas por post-usuarios, es decir, personalización “prompt ready”.
    • Microsoft, Google, Adobe, Autodesk, Salesforce, SAP… irán seguramente a este modelo de Plataforma base+personalización “prompt ready”. Ya lo estaban haciendo con el “low-code/”No-code”.
  • Aportación brutal de valor en Efecto red y Conocimiento.
    • Empresas pequeñas y de nicho, como CYPE, Presto, Prinex, Tekton 3D, Istram deben ir a este modelo.

Preguntas frecuentes sobre el diseño del marco

¿Por qué respuestas binarias (Sí/No)?

El marco usa respuestas binarias a propósito. Cuando evaluamos una idea de la que estamos encaprichados, cualquier escala numérica (de 0 a 5, por ejemplo) invita a matizar las respuestas para que el resultado confirme lo que queremos oír. Un “3 de 5” suena razonable, un “parcialmente” parece prudente, pero ambos son formas elegantes de evitar la honestidad.

El formato Sí/No elimina esa zona de confort. Te obliga a decidir: ¿tu idea tiene esta barrera o no la tiene? No hay medias tintas. Esto funciona tanto a favor como en contra de tu idea: una barrera que creías parcial puede revelarse como inexistente cuando te fuerzas a elegir, pero también puede confirmarse como sólida cuando dejas de infravalorarla.

El objetivo no es ser punitivo sino ser honesto. Es mejor descubrir que tu idea no tiene peso antes de invertir seis meses en ella, que descubrirlo después.

¿Por qué no se analiza la experiencia de usuario (UX)?

La UX no aparece como dimensión propia porque se considera parte del Conocimiento dentro de Dominio. Diseñar una buena experiencia de usuario requiere entender cómo el usuario espera que funcione el software en su contexto específico, qué flujos de trabajo son naturales en su sector y qué fricciones son aceptables o inaceptables. Eso es conocimiento de dominio aplicado a la interfaz.

Además, hoy en día la IA genera UX generalista de calidad sorprendentemente buena. Interfaces limpias, navegaciones estándar y patrones de diseño comunes están al alcance de cualquiera con un prompt bien formulado. Lo que la IA no puede generar es la UX específica de un sector: saber que un radiológo necesita comparar imágenes de una forma concreta, o que un gestor portuario necesita ver cierta información en un orden específico durante una ventana de tiempo crítica. Eso es expertise, no diseño.

¿Por qué no hay eje temporal?

El marco busca deliberadamente barreras que sean relativamente sólidas frente al avance de la IA, no ventajas temporales que se erosionen en meses. Por eso no incluye un eje explícito de tiempo: las tres dimensiones (Dominio, Arquitectura, Operación) están elegidas precisamente porque resisten mejor que otras al progreso tecnológico. El conocimiento tácito no se digitaliza de la noche a la mañana, la ciberseguridad certificada no se improvisa, y la responsabilidad legal no se delega a un algoritmo.

Dicho esto, ninguna barrera es eterna. La recomendación es revisar las conclusiones del análisis PODA periódicamente (cada 6–12 meses como mínimo) para evaluar si las barreras que identificaste siguen siendo reales o si la IA ha avanzado lo suficiente como para debilitarlas.

¿Por qué no se incluyen la distribución y el canal actual?

Tener una base de clientes establecida, un canal de ventas funcional o una marca reconocida son activos reales que protegen un negocio. Pero el marco PODA no los evalúa porque su objetivo es identificar debilidades y amenazas, no sentenciar a muerte. Un producto con excelente distribución pero sin peso en ninguna dimensión del PODA no está muerto hoy, pero sí está en una posición vulnerable que merece atención.

La distribución es un amortiguador temporal, no una barrera estructural. Compra tiempo, pero no resuelve el problema de fondo. Si tu único diferencial frente a la IA es que ya tienes clientes, la pregunta no es si esos clientes se irán, sino cuándo encontrarán una alternativa lo suficientemente fácil como para plantearse el cambio.

¿Por qué no se evalúan la “fricción” comercial o el “data gravity”?

Es común confundir las defensas contra la competencia tradicional (fosos de negocio) con las defensas contra la Inteligencia Artificial (supervivencia tecnológica). El marco PODA evalúa estrictamente lo segundo.

Conceptos clásicos como la fricción de salida (lo que cuesta abandonar una plataforma por otra) o el data gravity (el “peso” de los datos acumulados) son excelentes métricas de retención, pero se comportan de forma distinta cuando el atacante no es una empresa rival, sino un usuario armado con IA:

Sobre la fricción y el efecto red: Lo que la IA comoditiza y abarata radicalmente es la creación de código, no la creación de comunidades. Si un usuario aislado utiliza un LLM para clonar tu plataforma a coste cero, el resultado será un cascarón vacío. Por lo tanto, el simple hecho de que tu software conecte a usuarios que interactúan entre sí ya es tu escudo contra la IA. La “fricción” que evita que esos usuarios se vayan a una alternativa de la competencia es un problema de estrategia comercial clásica. Para el marco PODA, te basta con tener la red.

Sobre los datos propios y el Data Gravity: Es cierto que los datos acumulados por un cliente en un software (SaaS) tienen “gravedad” y cuesta moverlos. Sin embargo, bajo las reglas del marco PODA, la evaluación es mucho más simple: si el software solo gestiona los datos propios de un usuario aislado, la respuesta a la pregunta de Dominio es directamente NO.

¿Por qué? Porque un cliente armado con IA y acceso a sus propios datos puede crearse una herramienta interna a medida. El verdadero foso defensivo en la dimensión de Dominio solo existe cuando hablamos de datos colectivos. La IA te permite programar un clon técnico de Google Maps o de Wikipedia en un fin de semana, pero no te permite generar los datos de tráfico en tiempo real de millones de coches ni el conocimiento colaborativo acumulado durante décadas. Si tu valor depende de datos que un usuario no puede generar por sí solo, tienes una barrera. Si solo depende de custodiar los datos del cliente, tarde o temprano la IA facilitará su salida.

¿Por qué no se incluyen los costes recurrentes de infraestructura?

El marco PODA evalúa si una idea tiene peso suficiente para justificar inversión profesional, no su viabilidad económica. Los costes recurrentes de infraestructura (servidores, hosting, almacenamiento) no se incluyen porque no son un elemento diferenciador: serán similares tanto si lo construye el cliente como si lo construye un profesional. La IA puede ayudar a configurar un servidor o a escribir scripts de despliegue, pero el coste mensual de la infraestructura no cambia en función de quién la provisione.

El siguiente paso tras el análisis PODA es un business case financiero clásico que incluya estos costes recurrentes junto con licencias y equipo. Eso es un ejercicio diferente que viene después: primero decides si tu idea tiene peso, luego haces los números.

¿Por qué llamarlo PODA?

El acrónimo P.O.D.A. no es casual. Aunque evalúa Dominio, Arquitectura y Operación (D.A.O.) para encontrar el “Peso” (que es la conclusión del análisis, no una dimensión en sí misma), elegí este nombre porque su función principal es actuar como unas tijeras de podar. Su misión es cortar rápido las ideas de software sin viabilidad comercial antes de que desperdicies tiempo y dinero en ellas.