Qué es una aplicación web en la práctica
Si tu equipo hoy resuelve la operación con hojas de cálculo, grupos de chat y archivos sueltos, una aplicación web pone esa operación en un solo lugar, con usuarios y reglas. Un cliente ve sus pedidos. Un asesor ve su cartera. Una persona de mostrador agenda y otra solo consulta. Devstoremx construye ese tipo de sistemas para negocios en México, trabajando en remoto.
No es el mismo encargo que una página web. La página convence a un desconocido. La aplicación la usa alguien que ya tiene una cuenta, una cita o un pedido. Meter las dos en el mismo proyecto es posible, pero se escriben como dos alcances, porque fallan por razones distintas: una por no explicar, la otra por guardar mal un dato.
El ejemplo público de seguimiento que hay en el sitio, el dashboard de cliente, usa datos ficticios. Sirve para mostrar cómo se ve un tablero de avance. No es el sistema de un cliente real y no se debe citar como caso.
Qué suele incluir el desarrollo
Cada sistema es distinto, pero el esqueleto que acotamos en la propuesta es este:
- Los roles: quién entra, qué puede ver y qué no debe poder borrar.
- Las pantallas que esos roles usan en una semana normal, no el catálogo infinito de “por si acaso”.
- Los datos que se guardan y los que se calculan. Un estado de pedido, una fecha de cita, un saldo.
- Los avisos: correo cuando algo cambia, si eso evita que el proceso se detenga.
- El acceso de administrador del negocio y una forma de sacar la información.
- El hospedaje de la aplicación, a nombre del negocio, con el costo del servidor separado del costo del desarrollo.
Lo que no entra salvo que se nombre: una app en las tiendas de Apple o Google, un rediseño del sitio público, o la carga histórica de diez años de archivos. Esas son fases.
Para quién es, y para quién es pronto
Es para un negocio que ya repite el mismo proceso y el proceso se rompe por el volumen: se pierden mensajes, dos personas editan la misma hoja, el cliente pregunta “¿en qué va lo mío?” y nadie tiene la misma respuesta.
Es pronto cuando el proceso todavía cambia cada semana. Construir software sobre un flujo que no se ha hecho a mano ni veinte veces produce un sistema rígido del experimento de ayer. En esa etapa a veces conviene una automatización corta o incluso seguir en la hoja, y lo decimos.
Tampoco sustituye a una app móvil si la persona tiene que trabajar sin señal, escanear en un almacén o recibir avisos con la app cerrada. Muchas operaciones se resuelven con la aplicación web bien hecha en el celular. Cuando no, se cotiza la app nativa o el envoltorio que corresponda, con los costos de las tiendas dichos aparte.
Cómo se evita un sistema que nadie usa
El riesgo de una aplicación a la medida es construir lo que se imaginó en una junta y no lo que se hace el jueves. Por eso la planeación baja a tareas: “la recepcionista cambia la cita”, “el cliente descarga su estado”, “el supervisor ve las de la semana”. Si una pantalla no tiene un usuario y una tarea, no entra en la primera versión.
También se escribe qué pasa con los errores: cita duplicada, pago no reflejado, usuario que olvidó la contraseña. Un sistema que solo muestra el camino feliz se cae el primer día de uso real.
Las conexiones con correo, pagos, hojas o un ERP se listan como integraciones. “Que se conecte con todo” no es un requisito: es una forma de no terminar.
Qué recibes al final
Al final hay un ambiente que el negocio puede usar, usuarios de prueba recorridos con el equipo y los accesos de la infraestructura. El código y las cuentas no se quedan como rehén. Si después hace falta una segunda versión, se cotiza con lo que ya se aprendió de la primera, no se reabre todo el proyecto por inercia.
