01
Portales de cliente
Sus clientes entran para ver su estado, sus documentos, su historial y sus facturas.
Desarrollo · 01.2
Aplicaciones que aguantan el uso diario.
Una demo tiene que funcionar una vez, en orden y con datos limpios. Una aplicación tiene que funcionar todos los días, con usuarios con prisa y datos desordenados. Nosotros construimos lo segundo.
01 / Qué es
Qué entendemos por web app.
02
Herramientas internas
Sustituyen las hojas de cálculo que se han quedado cortas: operaciones, inventario, planificación y aprobaciones.
03
Reservas y flujos de trabajo
Procesos por pasos con estados y reglas: citas, solicitudes, altas y aprobaciones.
04
Paneles
Datos sobre los que se actúa, no gráficos decorativos. Lo difícil es elegir y defender la primera pantalla.
02 / incluido
Qué incluye desarrollar una aplicación.
Una aplicación conlleva obligaciones que un sitio corporativo no tiene.
Autenticación y roles
Permisos definidos como un modelo, no como comprobaciones dispersas.
Un modelo de datos de verdad
Relaciones, restricciones y migraciones en PostgreSQL.
Todos los estados diseñados
Carga, vacío, error, parcial y sobrecarga.
Tests donde compensan
Tests automáticos en la lógica donde un fallo silencioso dolería: dinero, permisos e integridad de datos.
Registro de auditoría
Quién cambió qué y cuándo.
Accesibilidad hasta WCAG AA
Recorridos de teclado y orden de foco.
03 / qué vigilar
Qué hace distinto el trabajo de aplicación.
Cada riesgo y cómo lo evitamos.
×La complejidad está en las reglas, no en el número de pantallas.
Reglas, datos y roles se ponen por escrito antes de diseñar pantallas.
×Los requisitos cambian en cuanto llegan los usuarios reales.
Un prototipo navegable temprano y bloques de ajuste de dos semanas.
×Migrar los datos existentes suele ser la semana más difícil.
La migración se planifica desde el modelo de datos, no se deja para el final.
×Cada rol nuevo multiplica las pruebas de permisos.
Los permisos se modelan en un solo lugar.
×El trabajo pasa de construir a mantener, sin fecha de fin.
Un acuerdo de soporte mensual desde el lanzamiento.
04 / cómo funciona
Cómo funciona.
Así trabajamos normalmente. El presupuesto fija las fechas reales antes de empezar.
Modelo
Datos, roles, reglas y flujos. Entregables: modelo de datos y mapa de flujos y roles.
Prototipo
El flujo principal navegable, con los nombres de campo reales. Entregables: prototipo navegable y alcance revisado.
Desarrollo
Iteraciones de dos semanas con despliegue continuo a un entorno de pruebas. Entregables: aplicación funcional y entregas quincenales.
Lanzar y mantener
Migración de datos, alta de usuarios y monitorización, seguidos de un acuerdo de soporte. Entregables: aplicación publicada y acuerdo de soporte.
05 / preguntas
Preguntas
No a partir de una descripción. La primera fase es el modelado, que termina en un alcance que se puede presupuestar con firmeza. Cualquier precio cerrado antes de eso es una suposición.
Normalmente sí, si el otro sistema tiene API. Si no, hay opciones como importaciones programadas, archivos o lecturas de base de datos. Conviene decidirlo en el alcance, porque afecta al modelo de datos.
Usted, en sus propias cuentas. El alojamiento y la base de datos tienen un coste moderado en la mayoría de aplicaciones, y documentamos la configuración para que no dependa de nosotros.
La mayoría de clientes pasa a un pequeño acuerdo mensual tras el lanzamiento: planificar los cambios sale más barato que tratar cada uno como un proyecto nuevo.
Ese es el objetivo: TypeScript en todo el proyecto, estructura convencional, documentación escrita, una sesión de traspaso y ningún framework propietario.
06 / también en desarrollo
El resto de Desarrollo.
Cuéntenos qué necesita construir.
Descríbanos el proyecto en unas líneas. Le respondemos con un plan, un calendario y un presupuesto cerrado, en un día laborable.