El área de operaciones armó en tres semanas una app en Power Apps para registrar las visitas a terreno. Funcionó tan bien que gerencia pidió abrirla a los 400 técnicos de los contratistas, conectarla al ERP y sumar un portal para que los clientes vean el estado de su servicio. Ahí empezaron las preguntas: quién paga las licencias de gente que no es de la empresa, por qué la búsqueda no encuentra registros antiguos y quién mantiene una app que se armó un fin de semana.
El desarrollo de aplicaciones empresariales hoy parte casi siempre con la misma duda: ¿lo hacemos en una plataforma low-code como Power Apps o lo construimos con código, en Angular, Node.js o el stack que corresponda? No hay una respuesta única, pero sí criterios bastante concretos que inclinan la balanza: quién va a usar la app, cuántos datos mueve, con qué se integra y cuánto cuesta por usuario. Si lo que tienes es un proceso manual que quieres automatizar, partimos por ahí en cuándo vale la pena automatizar con Power Platform.
Qué resuelve bien cada enfoque
Partamos por descartar un prejuicio: low-code no es desarrollo para quienes no saben programar, y el código a medida tampoco es por definición la opción seria. Cada uno calza mejor con cierto tipo de problema.
Una plataforma low-code como Power Apps rinde cuando la app es interna, la usan personas que ya tienen cuenta en Microsoft 365, los datos viven en SharePoint, Dataverse o SQL, y el proceso cambia seguido. Se construye rápido, se modifica rápido y el área de negocio puede participar de verdad en el diseño.
El desarrollo con código tiene sentido cuando la app la usan clientes, proveedores o el público, cuando la interfaz o la experiencia de usuario son parte del producto, cuando hay volúmenes de datos grandes o lógica compleja, o cuando la empresa necesita controlar por completo dónde corre, cómo escala y quién tiene el código.
Lo complicado es el medio: la app interna que de a poco empieza a tener usuarios externos, o el formulario simple que termina siendo un sistema.
Cinco criterios para decidir
1. Quién va a usar la aplicación
Es el criterio que más pesa, porque define el modelo de licencias. Si los usuarios son empleados con Microsoft 365, una app hecha en Power Apps con conectores estándar (SharePoint, Outlook, Teams) puede no requerir licencias adicionales, salvo que corra en un entorno administrado (managed environment), donde todo uso activo exige licencia premium. Si los usuarios son externos, el escenario cambia: Power Apps para usuarios internos se licencia por persona, y para clientes o proveedores Microsoft ofrece Power Pages, que se licencia por capacidad (paquetes de usuarios autenticados o anónimos por sitio y por mes). Una aplicación web desarrollada con código no paga por usuario, aunque sí paga hosting, mantenimiento y desarrollo.
2. Cuántos datos y qué tipo de consultas
Power Apps funciona bien con fuentes de datos grandes siempre que las consultas se puedan "delegar" a la base de datos. Cuando una fórmula no es delegable, la app trae solo los primeros 500 registros por defecto, ampliables hasta un máximo de 10.000, y opera sobre ellos. Lo documenta Microsoft: si el registro que buscas es el 501, la búsqueda no lo encuentra y no avisa al usuario. Se puede diseñar alrededor de esto con Dataverse, vistas y filtros delegables, pero exige disciplina. Una app con reportes complejos sobre cientos de miles de registros suele estar más cómoda con un backend propio.
3. Con qué se tiene que integrar
Los conectores estándar de Microsoft 365 están incluidos. Dataverse, los conectores premium (SQL Server, por ejemplo) y los conectores personalizados hacen que la app pase a ser premium, y cada usuario que la ejecuta necesita una licencia que dé ese derecho. Si la app debe conversar con un ERP on-premise, un AS/400 o una API bancaria, la pregunta es si basta un conector o si conviene una capa de integración propia que después sirva a varias aplicaciones.
4. Cuánto va a cambiar y quién la mantiene
Low-code anda mejor cuando el proceso cambia cada mes y alguien del negocio puede ajustar un formulario sin abrir un proyecto. El riesgo está en el otro extremo: apps críticas que hizo una persona que ya no está, sin control de versiones ni ambientes de prueba. El código a medida, por su parte, trae su propio mantenimiento: frameworks que salen de soporte, dependencias y despliegues. Lo vimos en detalle en qué pasa con el software a medida tras la entrega.
5. Cuánto cuesta en tres años, no en el primer mes
El costo de arranque de low-code es bajo. El costo recurrente crece con cada usuario. Con código pasa lo contrario: inversión inicial mayor y costo recurrente menos atado a la cantidad de usuarios. Por eso conviene comparar a tres años y con el número de usuarios que realmente esperas, no con el piloto.
Tabla comparativa
| Criterio | Power Apps (low-code) | Desarrollo con código |
|---|---|---|
| Usuarios típicos | Empleados con Microsoft 365 | Clientes, proveedores, público o equipos grandes |
| Tiempo hasta la primera versión | Semanas | Semanas a meses, según alcance |
| Licencias | Por usuario (o por capacidad en Power Pages) | Sin licencia por usuario; hosting y mantenimiento |
| Volumen de datos | Bien con consultas delegables; cuidado con los límites | Sin límites impuestos por la plataforma |
| Interfaz | Plantillas y controles de la plataforma | Totalmente a medida |
| Quién puede modificarla | Negocio y TI, con gobierno | Equipo de desarrollo |
| Riesgo principal | Apps sin dueño y licencias que se disparan | Mantenimiento y deuda técnica |
Lo que cambia en licencias de Power Apps
Hay un punto que muchas empresas no tienen en el radar. Microsoft anunció que desde febrero de 2027 aplicará de forma estricta requisitos de licencia que hasta ahora se aplicaban con holgura: apps en entornos administrados, apps basadas en modelos y apps personalizadas usadas fuera del contexto de una licencia de Dynamics 365. Los usuarios sin una licencia premium adecuada no podrán abrir esas apps hasta que se les asigne una. Microsoft aclara que el requisito no es nuevo; lo que cambia es que ahora se va a hacer cumplir.
Si ya tienes apps en Power Apps, descarga los reportes de licencias del centro de administración de Power Platform y revisa cuáles quedan en esa situación antes de sumar nuevas. Como referencia, la página de precios oficial muestra Power Apps Premium a USD 20 por usuario al mes con pago anual (precio de lista en EE.UU.); también existen el plan por app y el pago por uso con una suscripción de Azure.
El camino intermedio: combinar ambos
No siempre hay que elegir uno. Algunos patrones que funcionan:
- Backend propio con API (en Azure, por ejemplo) y una app de Power Apps para el uso interno, conectada por un conector personalizado. El portal para clientes se construye con código sobre la misma API.
- Prototipo en Power Apps para validar el proceso con usuarios reales y, si la app crece hacia usuarios externos o volúmenes altos, reconstrucción con código usando lo aprendido.
- Power Automate para los flujos de aprobación y notificaciones alrededor de una aplicación hecha a medida.
Sea cual sea la combinación, deja la decisión por escrito: qué se hace en cada plataforma, quién es el dueño y cuándo se revisa.
Preguntas frecuentes
¿Power Apps sirve para aplicaciones que usan clientes externos?
Para eso Microsoft ofrece Power Pages, que se licencia por capacidad de usuarios por sitio y por mes. Conviene calcularlo con el volumen real de usuarios y compararlo con el costo de una aplicación web propia.
¿Una app de Power Apps se puede migrar después a código?
No hay conversión automática, pero el proceso, los datos y las reglas de negocio validados en la app low-code ahorran buena parte del análisis del desarrollo posterior.
¿Si tengo Microsoft 365 ya tengo Power Apps incluido?
Microsoft 365 incluye derechos para usar Power Apps con conectores estándar. Si la app usa Dataverse, conectores premium o personalizados, cada usuario necesita una licencia premium.
Antes de elegir herramienta, haz la cuenta
En Disrupsoft desarrollamos aplicaciones web y móviles a medida con Angular, Node.js y Azure, y también trabajamos con Power Platform, así que la conversación parte por el proceso y por cuánto va a costar la app en tres años, no por la herramienta. Si estás evaluando cómo construir tu próxima aplicación, conversemos sobre tu proyecto de desarrollo de software a medida.
