Aplicaciones web a medida en Marruecos

Problemas de negocio

• Software de estantería que pelea con el almacén, la flota o finanzas, obligando al personal a rodear la herramienta en vez de usarla.
• Hojas que llevan una operación real hasta que fallan, normalmente en el peor momento — fin de mes, un pedido grande — donde el fallo cuesta más.
• Una construcción “a medida” anterior que en realidad es un montón de scripts sin mantener que nadie en el equipo actual entiende ni se atreve a tocar.
• Un flujo repartido en tres herramientas distintas con datos reintroducidos a mano entre ellas, así que la «fuente de verdad» es en realidad la última herramienta que alguien consultó.
• Un desarrollo a medida anterior sin tests ni documentación, así que cada cambio es una apuesta sobre qué más podría romper.
• Un flujo que funciona para el caso normal en una demo pero no tiene comportamiento definido para los casos límite — un artículo devuelto, un pedido cancelado — que en realidad componen una fracción real de las operaciones diarias.
• Sin plan para lo que pasa cuando la persona que entiende el sistema a medida se va, así que el conocimiento institucional se va con ella.

Proceso de desarrollo

1. Descubrir el flujo. Modelar entidades del suelo. Entregar un módulo fino — una sola pantalla real haciendo un trabajo real — antes de construir el resto.
2. API Laravel, UI React, producción en Linux — como FRIGO SYS y AnyWare, elegidos porque son aburridos de la forma en que la infraestructura debe ser aburrida.
3. Entregar un sistema que el propio equipo del cliente — o el siguiente desarrollador — pueda leer de verdad, con un modelo de datos nombrado según el vocabulario propio del negocio, no sustantivos genéricos de framework.
4. Sustituir primero la reintroducción manual entre herramientas por una única fuente de verdad, incluso antes de pulir la UI, ya que ahí es donde se pierde el tiempo de verdad.
5. Escribir tests para las partes del sistema donde un bug silencioso costaría dinero de verdad — facturación, stock, permisos — incluso cuando el resto de la UI no está totalmente cubierto.
6. Mapear los casos límite — devoluciones, cancelaciones, correcciones — con el mismo cuidado que el caso normal, ya que en la mayoría de negocios reales no son raros en absoluto.
7. Documentar el modelo de dominio del sistema y las decisiones clave como parte de la entrega, no como algo posterior, para que el conocimiento no se vaya cuando se va una persona.

Qué obtienes

• Software alineado con cómo opera de verdad la empresa, en vez de que la empresa remodele su proceso para encajar con el software.
• Un solo dueño para todo el sistema, para que un reporte de bug no rebote entre la cola de soporte de un proveedor SaaS y un equipo interno que no ve la otra mitad del problema.
• Una sola fuente de verdad en vez de los mismos datos tecleados en tres herramientas confiando en que se mantengan sincronizados.
• Confianza para cambiar el sistema, porque las partes donde un bug costaría dinero están realmente probadas.
• Casos límite — devoluciones, cancelaciones, correcciones — gestionados por el sistema en vez de sorteados a mano porque nadie los modeló.
• Conocimiento institucional que sobrevive a un cambio de equipo, porque el modelo de dominio y las decisiones clave están documentados, no solo recordados.

Proyectos seleccionados