La diferencia en una frase
Un sitio web publica información. Una aplicación web guarda un estado y ejecuta un proceso.
Esa es toda la distinción. Un sitio le dice a la gente qué haces, dónde estás y por qué deberían llamarte, y su contenido cambia cuando tú decides cambiarlo. Una aplicación sabe quién está dentro, recuerda qué hizo la última vez, impone reglas sobre qué pasa después y produce un resultado distinto para cada usuario.
Un formulario de contacto no convierte un sitio web en una aplicación. Tampoco un inicio de sesión que solo desbloquea una página de descargas. La prueba es si el sistema le está siguiendo la pista a algo que cambia según su propio ritmo y no según el tuyo.
Las señales de que ya te quedó chico un sitio web
Casi ninguna aplicación se encarga: se descubre, normalmente cuando un negocio se da cuenta de cuánto de su proceso real está sostenido a mano. Las pistas habituales:
- Una hoja de cálculo que editan más de dos personas, que nadie se atreve a reestructurar y que alguien tiene que reconciliar cada semana.
- La misma información escrita en dos sistemas, porque ninguno le habla al otro.
- Un proceso que solo una persona entiende por completo, y que se detiene cuando se toma una semana.
- Clientes que escriben para preguntar un estado que alguien tiene que ir a consultar.
- Un informe que a una persona le toma media jornada cada mes armar a mano.
- Una carpeta creciente de plantillas de documentos que se llenan y se renombran.
Si varias de esas son ciertas, ya estás operando una aplicación. Simplemente la están ejecutando personas, y el costo de operarla es su tiempo más los errores.
Compra antes de construir
El software a medida más barato es el que no tuviste que escribir. Antes de construir nada, la pregunta honesta es si un producto que ya existe hace esto, porque una suscripción casi siempre le gana a un desarrollo tanto en costo como en tiempo.
Los productos existentes suelen ser la respuesta correcta cuando tu proceso es uno común con otro vocabulario: agendas, facturación, CRM, seguimiento de proyectos y tickets de soporte son problemas resueltos. Pagar la herramienta específica de la industria y adaptar un poco tu proceso es el intercambio sensato.
Construir es la respuesta correcta cuando se cumple alguna de estas:
- El proceso es tu ventaja competitiva real, y hacerlo de la manera genérica elimina la razón por la que los clientes te eligen.
- Ya evaluaste los productos de la categoría y cada uno necesita tanta personalización que vas a construir igual, pero dentro de las restricciones de otro.
- El costo de suscripción escala con algo de lo que tienes mucho —usuarios, sucursales, transacciones— y la cuenta se volvió en contra de alquilar.
- Necesitas conectar varios sistemas que ya pagas, y la integración es el producto.
- Tus datos no pueden estar en el sistema de un tercero, por razones contractuales o normativas.
Cuánto cuesta una aplicación, y por qué es distinto
Un sitio web es sobre todo un costo único con un mantenimiento moderado. Una aplicación es un compromiso con un costo corriente, y el desarrollo muchas veces es la mitad más pequeña a cinco años.
Las partes que se olvidan al presupuestar:
- Hosting que escala con el uso, más base de datos y respaldos, cada mes.
- Servicios de terceros de los que depende la aplicación: pagos, entrega de correo, autenticación, almacenamiento de archivos y todo lo que se cobre por uso.
- Actualizaciones de seguridad de los frameworks y las librerías de abajo, que no son opcionales en nada que guarde datos de clientes.
- Cambios. Una aplicación que se usa va a generar peticiones, porque la gente encuentra sus bordes en cuanto se vuelve real.
- Soporte, incluida la pregunta que llega a las siete de la tarde porque alguien no puede terminar su trabajo.
Esta es la parte sobre la que vale la pena ser directo. Si no hay presupuesto para el segundo año, la respuesta correcta normalmente es un producto ya hecho o una versión más pequeña de la idea, no un desarrollo que no puedes mantener. Una aplicación abandonada es peor que la hoja de cálculo que reemplazó.
Cuentas, roles y pagos
En el momento en que un sistema tiene usuarios aparecen tres preguntas que un sitio web nunca tiene que contestar, y moldean todo lo que se construya después. Decidirlas temprano es barato; descubrirlas tarde es reescribir.
¿Quiénes son los usuarios, y pertenecen a organizaciones? Si una cuenta puede tener varias personas con permisos distintos, ese es un diseño diferente al de una cuenta por persona, y adaptarlo después es uno de los cambios más caros que existen.
¿Qué puede ver y hacer cada rol? No como una lista de pantallas, sino como una regla sobre registros: un gerente ve su sucursal, un dueño ve todas, un cliente ve solo lo suyo.
¿Se mueve dinero, y en qué dirección? Cobrarle a clientes es sencillo. Pagarle a otras personas a través de tu plataforma es otro problema, con verificación de identidad y manejo de pagos de salida, y conviene nombrarlo el primer día en lugar de tratarlo como una función para después.
Datos, accesos y las obligaciones aburridas
Guardar datos de otras personas trae obligaciones que llegan aunque nadie las haya planeado. Ninguna de estas es difícil si se diseña desde el principio, y todas son dolorosas de agregar después.
Quién puede ver qué, impuesto por el sistema y no por costumbre. Una aplicación en la que cualquier usuario con sesión puede llegar a cualquier registro cambiando un número en la dirección es la falla grave más común que encuentro en sistemas heredados.
Qué pasa cuando alguien deja la empresa, y si su acceso de verdad termina. Una vía de exportación, para que tus datos no queden rehenes de la aplicación. Y un registro de quién cambió qué, que suena a lujo hasta la primera discusión sobre un monto.
Si manejas datos de salud, financieros o de menores, las reglas aplicables son una entrada del diseño y no una revisión de cumplimiento al final. Dilo en la primera conversación.
Empieza por un solo proceso
La forma más común en que fracasa el software a medida es especificarlo completo antes de que nadie haya usado nada. Un documento que describe todo lo que el sistema debería llegar a hacer es una lista de deseos, y las partes que nadie necesitaba son indistinguibles de las que importan hasta que está corriendo.
Una mejor forma: elige el único proceso que hoy cuesta más trabajo manual, constrúyelo bien y ponlo frente a la gente que hace ese trabajo. Ellos te van a decir cuál es la siguiente pieza, y van a tener razón más veces que el documento.
Esto también protege el presupuesto. Una primera entrega en semanas que reemplaza una hoja de cálculo vale más que un desarrollo de seis meses que llega todo de golpe, y te da una base real para decidir si continuar.
Cuando necesitas las dos cosas
Muchos negocios necesitan un sitio web y una aplicación, y lo mejor es mantenerlos como dos cosas separadas que se enlazan entre sí. El sitio es público, rápido y hecho para que lo encuentren en la búsqueda. La aplicación vive detrás de un inicio de sesión y está hecha para la gente que la usa a diario.
Intentar que un solo sistema haga las dos cosas normalmente termina con un sitio público ralentizado por software que no necesita, y una aplicación limitada por un gestor de contenidos contra el que pelea. La versión limpia es un sitio de marketing que posiciona, con un acceso que entrega a los usuarios a la aplicación.
Si la parte pública es la que necesitas primero, eso es un sitio web para negocios, y la guía de costos cubre lo que define su precio.
Por qué este no es un servicio local
Nadie busca software a medida por ciudad, y el trabajo de aplicaciones no depende de estar cerca. Corre sobre llamadas, documentos compartidos y un entorno de pruebas que puedes abrir desde cualquier parte, así que lo trato como regional y no ciudad por ciudad.
Donde la cercanía ayuda de verdad es en la primera fase, cuando el trabajo consiste en entender un proceso viendo a la gente hacerlo. Para eso, los clientes del suroeste de Florida tienen la opción de estar en la misma sala. Todo lo que viene después corre igual estés en Fort Myers o no.
Averiguar cuál de las dos necesitas
Si no estás seguro, describe el proceso en lugar del software. Qué pasa hoy, quién lo toca, dónde se atora y qué se escribe dos veces. La respuesta normalmente se vuelve evidente en esa conversación, y a veces es un producto ya hecho, lo cual es un resultado perfectamente bueno.
Mi servicio de aplicaciones web empieza ahí. Como ejemplos construidos: Paganki es una plataforma SaaS multiempresa con pagos por Stripe Connect en cinco idiomas, Parking Operations Analytics convierte datos de transacciones en vivo en informes de ingresos por turno en varios estacionamientos, y la AX AI Support Platform es un sistema de recuperación sobre tres proveedores de modelos de lenguaje.