Hay un momento que casi todos los dueños de pyme reconocen. El sitio o la herramienta que hace un tiempo resolvía todo ahora te obliga a hacer malabares: una planilla al costado, un mensaje para avisar que cargaron mal un dato, una tarea que solo sabe hacer una persona. Ahí aparece la pregunta por un sitio web o aplicación web a medida.
Pasar a algo a medida no es un ascenso automático ni un capricho técnico. Es una decisión razonable cuando el límite está en el modelo de la herramienta y no en cómo la usamos. Acá va un criterio simple para distinguir un caso del otro.
Qué significa "a medida" (y qué diferencia a un sitio de una aplicación)
Un sitio web comunica y capta: presenta la empresa, explica lo que hacés, publica contenido y recibe consultas. Una aplicación web guarda estado: tiene usuarios que entran, datos que cambian y reglas propias sobre quién puede ver o hacer qué.
"A medida" quiere decir que la solución se construye sobre las reglas de tu negocio, en lugar de adaptar tu negocio a lo que la herramienta permite.
Muchas necesidades reales son mixtas: un sitio público para que te encuentren y una zona privada donde los clientes consultan pedidos. Conviene pensar cada superficie por separado.
En este terreno aparece seguido la sigla PWA. MDN las describe como aplicaciones web que usan APIs y funciones emergentes del navegador, junto con mejora progresiva, para ofrecer una experiencia parecida a la de una aplicación nativa, y aclara que son un patrón de diseño útil, pero no un estándar formalizado.
Hasta dónde llegan bien una plantilla, un CMS o una herramienta no-code
Si tu necesidad es común, lo estándar suele ser lo razonable. Presentar la empresa, publicar novedades, tener un formulario o un catálogo simple son problemas que muchos negocios comparten y para los que existen herramientas maduras.
El límite aparece cuando lo que necesitás ya no es una configuración sino una regla propia. Configurar es elegir entre opciones que la herramienta ya previó. Una regla propia es algo que no previó y que hay que simular con trucos.
Cuando lo estándar es la respuesta correcta
Si podés describir tu necesidad con las mismas palabras que usaría cualquier negocio del rubro, probablemente lo estándar alcance. Lo mismo si el problema es que el sitio se ve viejo o que falta contenido: eso se resuelve con diseño y redacción, no necesariamente con desarrollo.
Cuando el límite no es de la herramienta sino del uso
Antes de cambiar nada, revisá tres cosas. ¿La herramienta está bien configurada o usamos una fracción de lo que ofrece? ¿Hay contenido desactualizado? ¿Hay un acuerdo interno sobre quién carga qué? Si al ordenar eso el problema desaparece, no era la herramienta. Si sigue igual con buen uso, el límite es del modelo.
Señales de que tu sitio o tu herramienta ya se quedó chica
No hace falta medir nada: son señales que se ven en el día a día, y cada una viene con una pregunta.
Trabajás alrededor de la herramienta
El equipo se adapta a la herramienta y no al revés: planillas paralelas, procesos que dependen de la memoria de alguien, tareas manuales que se repiten porque la plataforma no las cubre. Preguntate cuántas cosas hacés de forma incómoda solo porque el sistema no permite otra.
Los datos viven en varios lugares
Los mismos datos se cargan a mano en dos o tres lugares, las versiones no coinciden y las integraciones se resuelven copiando y pegando. Preguntate si existe un lugar único con la información correcta.
Tu diferencial no entra en la plantilla
Lo que distingue a tu negocio, como una regla de cotización particular o una forma propia de coordinar turnos, no se puede expresar en la plataforma, así que se simula. Y cada cambio simple se vuelve un proyecto. Preguntate si lo que más te diferencia es justo lo que menos podés hacer con lo que tenés.
Un ejemplo hipotético: una pyme de servicios recibe pedidos por un formulario del sitio. Alguien los copia a mano a una planilla, otra persona los reasigna por mensajería y una tercera actualiza el estado cuando el trabajo termina. Cada pedido pasa por demasiadas manos.
Cuando el cuello de botella es un sitio público que ya no acompaña a la empresa, suele ser momento de conversar con un equipo de diseño y desarrollo web.
Cuándo el problema ya no es un sitio: es una aplicación
Hay un punto donde estirar la plantilla deja de tener sentido: aparecen usuarios que inician sesión, roles y permisos distintos, datos que cambian todo el tiempo y estados de un proceso, como un pedido que pasa de recibido a entregado. Eso ya es una aplicación, aunque hoy viva disfrazada de sitio. La parte pública sigue necesitando ser encontrable; la privada, no.
Lo que se ve y se rastrea vs. lo que es privado
Las páginas públicas tienen que poder rastrearse. La guía de Google Search Central sobre fundamentos de SEO para JavaScript explica que Google procesa las aplicaciones en JavaScript en tres fases (rastreo, renderizado e indexación) y que el contenido que depende de JavaScript necesita renderizarse para poder verse. No dice que esas aplicaciones no posicionen; sí aclara que renderizar en el servidor o pre-renderizar sigue siendo buena idea, porque acelera el sitio para usuarios y rastreadores y no todos los bots ejecutan JavaScript.
Para lo que está detrás de un login, la misma guía recomienda usar códigos de estado HTTP con sentido y menciona uno específico para páginas con autenticación. Para lo que no querés que aparezca en los resultados existe noindex. La explicación de Google sobre cómo bloquear la indexación suma un detalle fácil de pasar por alto: la página no debe estar bloqueada por robots.txt, porque si Google no puede acceder, nunca ve la regla.
Aplicación web, app móvil o ambas
Es frecuente que la primera etapa sea una aplicación web y que la pregunta por una app móvil se responda después, mirando el uso real: quién la usa, desde dónde y con qué frecuencia. Decidirlo de entrada es adelantarse. Si lo que tenés en mente son aplicaciones y paneles pensados para tu operación, conviene abrir esa conversación con el proceso bien descrito.
Lo que "a medida" te pide a vos: la contracara que conviene mirar
Algo propio implica decisiones, mantenimiento, seguridad y una persona interna que sepa qué se construyó y por qué. No es un argumento en contra: es una condición que conviene mirar antes de decidir.
Propiedad, accesos y continuidad
Preguntas para hacerte antes de avanzar, con cualquier proveedor:
- ¿Quién es dueño de los accesos, del código y de los datos?
- ¿Quién decide las prioridades cuando hay más pedidos que capacidad?
- ¿Qué pasa si cambia tu equipo o si quien lo construyó deja de estar disponible?
Si no tenés respuesta clara, conviene resolverlo antes de empezar y no después.
Seguridad y control de acceso desde el diseño
Una aplicación con usuarios y datos tiene riesgos distintos a los de un sitio informativo, empezando por quién puede ver qué. Que algo sea a medida no lo hace más seguro por sí mismo: depende de cómo se construye y se mantiene, y es una responsabilidad continua, no un tilde final.
Hay estándares abiertos para hablar de esto con criterio. El Application Security Verification Standard de OWASP ofrece una base para probar los controles técnicos de seguridad de las aplicaciones web y una lista de requisitos para desarrollar de forma segura. El OWASP Top 10 es un documento de concientización que refleja un amplio consenso sobre los riesgos más críticos en aplicaciones web. Conviene saber que existen para poder preguntar por ellos.
Qué no conviene perder al pasar a algo propio: rendimiento y visibilidad
Un desarrollo a medida no garantiza por sí mismo buena experiencia ni buena visibilidad: hay que medirlas. Para eso hay un lenguaje común. web.dev describe los Core Web Vitals como el subconjunto de Web Vitals que aplica a todas las páginas y que todo dueño de sitio debería medir. Miran tres aspectos de la experiencia: la carga (LCP), la interactividad (INP) y la estabilidad visual (CLS). Sirven para que, en lugar de pedir "que ande rápido", puedas hablar de qué se mide y cómo.
Si tu sitio actual ya trae búsquedas, cambiarlo tiene riesgos de migración, y eso es un tema aparte, que se explica en cómo cuidar el SEO cuando cambia un sitio que ya posiciona. Y si te preguntás con qué tecnología construir, es otra conversación, que se explica en elegir tecnología según el tipo de proyecto.
Un criterio de decisión en cinco preguntas
Respondé cada una con sí, no o no sé.
- ¿El proceso que necesitás es estándar o propio? Si cualquier negocio del rubro lo haría igual, probablemente sea estándar.
- ¿Adaptarte ya cuesta más de lo que la herramienta te da? Sumá el tiempo del equipo, los errores y lo que dejás de hacer.
- ¿Hay datos y usuarios con reglas de acceso? Si personas distintas ven o hacen cosas distintas, ya hablamos de una aplicación.
- ¿Podés sostener algo propio? Hace falta un responsable interno y disposición a mantenerlo vivo.
- ¿Podés avanzar por etapas en vez de reemplazar todo? Cuanto más se pueda dividir, menor el riesgo.
Cómo leer tus respuestas
Si la mayoría apunta a "propio", vale la pena evaluar algo a medida. Si son mixtas, lo más sano es separar superficies y decidir por partes. Si prevalece lo estándar, probablemente alcance con ajustar lo que ya tenés. No hay puntajes.
Un ejemplo hipotético: una pyme revisa su operación y separa dos grupos. Lo que resuelve con lo que ya usa, como el sitio institucional y un formulario de contacto, y lo que necesita ser propio, como un seguimiento de pedidos con acceso por cliente. En lugar de reemplazar todo, decide encarar solo lo segundo.
Qué llevar a una primera conversación
Te sirve llegar con cuatro cosas: cómo se hace hoy el proceso, qué herramientas usan, quién las usa y qué es lo que más duele. Alcanza con poder contarlo. Y si ya decidiste contratar, una matriz para comparar propuestas te ayuda a ordenar esa elección.
Preguntas frecuentes
¿Cómo sé si el límite es de la herramienta o de cómo la estamos usando?
Probá primero la configuración, el contenido y el orden interno. Si con buen uso el problema persiste, es del modelo de la herramienta: te pide una regla propia que no puede expresar.
¿Un sitio a medida es lo mismo que una aplicación web?
No. El sitio comunica y capta; la aplicación maneja usuarios, datos y procesos. Pueden convivir: una parte pública para que te encuentren y una privada para operar.
¿Pasar a medida implica descartar todo lo que ya tengo?
No necesariamente. Como criterio general, se puede decidir por partes y conservar lo que funciona. Lo importante es identificar qué superficie tiene el límite y encarar esa.
¿Una aplicación web privada necesita SEO?
La parte pública sí necesita ser rastreable. Lo que está detrás de un login no debería indexarse: según Google, se usa un código de estado con sentido para páginas con autenticación y noindex para lo que no querés que aparezca, sin bloquearlo en robots.txt.
Si ya notás que se te quedó chico
El criterio, en una línea: si el límite es del uso, ajustá; si es del modelo de la herramienta, evaluá algo propio, por etapas y con un responsable de tu lado.
Si estás en ese punto, contanos qué proceso o qué sitio hoy se te queda corto y lo miramos juntos, para ver si vale la pena algo a medida o si alcanza con ajustar lo que ya tenés. Si es un sitio, podés contarnos qué sitio se te quedó corto; si es una herramienta interna, podemos pensar una herramienta propia para tu operación.
Fuentes
- Aplicaciones Web Progresivas — MDN Web Docs
- fundamentos de SEO para JavaScript — Google Search Central
- bloquear la indexación con noindex — Google Search Central
- Application Security Verification Standard (ASVS) — OWASP
- OWASP Top 10
- Web Vitals — web.dev
