Aplicación web, app nativa y sitio institucional
Una página institucional presenta servicios y caminos de contacto. Una aplicación permite realizar tareas: cargar una venta, consultar una cuota o cerrar una orden. Una aplicación web se usa desde un navegador y puede comunicarse con un servidor para consultar o guardar información. MDN explica ese intercambio de solicitudes y respuestas entre cliente y servidor en la fuente técnica enlazada al final.
La expresión apps a medida no define por sí sola dónde se ejecuta el software. Si necesitás una instalación nativa, funciones particulares del dispositivo o trabajo sin conexión, pedilo como un requisito y revisá su viabilidad. Una web que se ve bien en el teléfono no demuestra ninguna de esas capacidades. En MaatWork el servicio publicado contempla aplicaciones web con base de datos, autenticación, roles y paneles.
Cuándo tiene sentido un desarrollo propio
Hacé una prueba con el sistema que ya tenés o con un producto del rubro: recorré una operación habitual y una excepción. Anotá dónde necesitás salir a una planilla, volver a cargar datos o pedir una autorización por chat. Si esas tareas son centrales, hay un problema concreto para evaluar. Si todo se resuelve con una configuración disponible, quizá convenga implementarla antes de encargar un desarrollo.
También puede ser razonable conectar herramientas existentes. Tener dos programas no obliga a reemplazarlos por uno nuevo. Primero verificá si permiten intercambiar los datos que necesitás, con qué permisos y bajo qué condiciones. La comparación tiene que incluir puesta en marcha, migración y operación futura. Comprar por cantidad de pantallas o por el nombre de una tecnología deja afuera lo que tu equipo va a hacer cada día.
Empezá por una tarea con principio y final
En lugar de pedir una app para administrar todo, describí una tarea: quién la inicia, qué información necesita y cuándo se considera terminada. Para un natatorio, podés empezar por registrar un alumno y consultar su cuota desde recepción. Para un taller, por recibir un equipo y seguir su orden. Escribí los estados con las palabras que usa tu equipo, incluso si todavía están en un cuaderno.
El caso Oro Azul muestra una relación entre ficha del alumno, grupos, cuotas y asistencia. MaatWork Extintores muestra equipos con historial y órdenes de taller. Son recorridos publicados que construimos; no implican que una empresa nueva necesite todas esas funciones. Elegir una tarea permite decidir qué datos son indispensables para la primera entrega y qué puede esperar sin interrumpir el trabajo.
Definí datos y permisos antes de las pantallas
Prepará una muestra anonimizada de tus datos y un glosario breve. Aclarar qué significa cliente activo, pago confirmado o equipo disponible evita que dos personas usen el mismo término para cosas distintas. Identificá los datos obligatorios, quién los carga y qué información no hace falta guardar. Si importás una planilla, distinguí errores que se corrigen de valores que deben conservarse como historial.
Después armá una matriz de permisos con acciones concretas: consultar, crear, corregir, anular y exportar. No alcanza con decir que habrá un administrador y un usuario. Recepción podría necesitar consultar cuotas sin modificar criterios de cobro; un técnico, actualizar su orden sin ver toda la administración. Son ejemplos de requisitos para discutir, no permisos incluidos automáticamente. El presupuesto debe describir qué se implementará y cómo se probará.
Diseñá también las excepciones y las integraciones
Una demostración preparada suele recorrer el caso que sale bien. Pedí ver qué pasa con un registro duplicado, un dato incompleto o una acción que necesita volver atrás. El objetivo es que la persona sepa si debe corregir algo, esperar o pedir ayuda. En Oro Azul, por ejemplo, las pantallas de conciliación separan comprobantes compartidos, repetidos o incompletos para revisión. Esa excepción está documentada en el caso.
Para integrar facturación, cobros o un sistema anterior, listá qué información entra y sale, quién administra la cuenta y qué ocurre si el otro servicio no responde. El acceso técnico no se supone: se verifica antes de cerrar el alcance. MaatWork publica un servicio de integraciones que incluye sincronización, importación, validación y manejo de excepciones según propuesta. Cada conexión nueva se confirma para la operación que la necesita.
Construí y validá por etapas
Una primera etapa tiene que permitir completar el recorrido acordado. Escribí ejemplos de aceptación en lenguaje cotidiano: una persona autorizada registra la operación, otra puede consultarla y el estado coincide con lo que ocurrió. Incluí también lo que no debe pasar. Si solo un rol puede anular un cobro, la validación necesita probar tanto el permiso autorizado como el intento de otro rol.
En la propuesta de MaatWork se definen alcance, entregables, etapas, tiempos y responsables de validar. Tu participación no termina en la primera reunión: alguien del negocio tiene que revisar el resultado con situaciones representativas. Dejá por escrito qué hace falta para empezar y qué cambios se cotizan aparte. No hay un plazo universal para una aplicación a medida; las dependencias y el trabajo acordado determinan la estimación.
Prepará la migración y el primer día de uso
Antes de importar, acordá qué registros pasan, cómo se identifican y quién valida los saldos o estados iniciales. Probá con una muestra y compará el resultado con la fuente. No hace falta llevar todo el historial si el negocio no lo necesita, pero la decisión debe ser explícita. También conviene fijar cuándo deja de editarse la herramienta anterior para evitar dos versiones operativas del mismo dato.
Ensayá el recorrido con quienes lo van a usar y en sus dispositivos habituales. Revisá dónde encontrar ayuda y cómo reportar un problema con contexto suficiente. La capacitación, el material y el acompañamiento se incluyen si forman parte de la propuesta. Publicar la aplicación no resuelve por sí solo quién carga la información ni quién responde cuando aparece una diferencia. Esas responsabilidades son parte de la puesta en uso.
Acordá cómo se mantiene y cómo se puede salir
Separá el costo de construir del costo de operar. Según el proyecto puede haber alojamiento, base de datos, correo, APIs, mantenimiento o soporte. Pedí que se indiquen responsables, límites y condiciones. También necesitás saber cómo se recuperan los datos y qué derechos de uso corresponden al código y los componentes. En MaatWork esos puntos quedan definidos en la propuesta y el contrato, no en una promesa universal de propiedad.
Para discutir seguridad podés usar OWASP ASVS como referencia de requisitos y verificación. Que un proveedor lo mencione no certifica su aplicación: pedí cuáles controles entran en el alcance y qué evidencia entrega. Las fuentes técnicas de MDN y OWASP enlazadas acá fueron consultadas el 22/10/2026. Si ya tenés un flujo para revisar, contanos cómo lo resolvés hoy y qué parte querés cambiar primero.
Preguntas frecuentes
¿Una aplicación a medida tiene que instalarse en el celular?
No necesariamente. Una aplicación web se usa desde el navegador. La instalación nativa, el trabajo sin conexión y las funciones particulares del dispositivo se evalúan como requisitos específicos.
¿Cuándo conviene una app a medida frente a un sistema existente?
Cuando hay reglas o tareas importantes que un producto no cubre y sostenerlas por fuera complica la operación. Antes de construir conviene probar productos disponibles y evaluar si alcanza con configurarlos o integrarlos.
¿Cuánto tarda desarrollar una aplicación?
No hay un plazo universal. Se estima por etapas según el flujo, los datos, los permisos, las integraciones y las validaciones que requiere el proyecto.
