Software desarrollado de inicio a fin: desde la arquitectura hasta el despliegue y el soporte en producción.
Diseñamos, construimos y desplegamos cada proyecto directamente. Sin intermediarios, sin subcontratación.
Cada ficha dice en qué punto está el proyecto —en producción, en piloto o en desarrollo— y lo que se ve son capturas de la aplicación funcionando.
Después del lanzamiento seguimos presentes: mantenimiento, mejoras y soporte técnico incluidos.
Zenth — PlataformaPlataforma full-stack en uso en tres planteles. El caso que se cuenta aquí es el del CBT No. 3 de Toluca, donde arrancó. Diseño, arquitectura y desarrollo de extremo a extremo realizados en CreativePixeLamb.
Sistema ERP a la mSistema de planeación de recursos empresariales desarrollado a la medida para gestionar y conectar las operaciones internas de una empresa, con automatizaciones de procesos entre sus áreas.
Las capturas de este caso son una recreación de la interfaz con datos de ejemplo: el sistema real opera con información del cliente y no es pública.
ERP multisede — prProducto propio en desarrollo: un ERP modular en español con más de 160 pantallas, permisos por área, segundo factor y aislamiento de datos por sede. Las capturas salen de la aplicación funcionando, con datos ficticios.
Capturas de la aplicación en funcionamiento. Los datos son de una empresa ficticia, cargados en local únicamente para estas imágenes.
Vendevo — Ventas aPlataforma de ventas en ruta para un distribuidor de alimentos: orden de entrega, inventario por lotes, venta desde el camión, cierre diario calculado por el sistema, tienda física y control de flota, con roles y auditoría.
Las capturas de este caso son una recreación de la interfaz con datos de ejemplo: el sistema real opera con información del cliente y no es pública.
Son de sectores distintos y resuelven problemas distintos, pero se construyeron con el mismo criterio.
Ninguno empezó como «hagamos una plataforma». Empezaron con alguien perdiendo horas cada semana en tareas que una computadora podía hacer: concentrar calificaciones que llegaban por mensajería, avisar uno por uno, capturar dos veces la misma información porque dos áreas usaban archivos distintos. El software vino después, como la forma más barata de quitar ese trabajo repetido.
En todos los casos, la parte más larga del diseño fue decidir cómo se guarda la información: qué es un alumno, qué es una entrega, qué relación tiene con un curso y un periodo; o qué es una orden, a qué área pertenece y en qué estados puede estar. Ese esquema relacional es lo que permite que después se puedan agregar módulos sin romper lo anterior, y lo que hace que los reportes cuadren sin reconciliaciones manuales.
Todos corren sobre Node.js con TypeScript en el servidor y en el navegador. Compartir tipos entre las dos mitades del sistema significa que un cambio en la forma de un dato aparece como error en el editor, no como un bug silencioso tres semanas después. Encima de esa base, cada proyecto usa lo que su problema pide: comunicación en tiempo real donde el aula la necesita, o un modelo de permisos por área y por sede donde hay varias plantas operando a la vez.
Esta es la diferencia que más importa. Un prototipo puede ignorar los casos raros; un sistema que va a operar no. Tiene que aguantar el día en que dos personas editan lo mismo al mismo tiempo, el archivo que alguien sube al revés, la conexión que se cae a media captura y el mes de cierre en que todos entran a la vez. Eso condiciona el diseño desde la primera tabla, no se parcha al final.
Ninguno se entregó y se archivó. Todos reciben correcciones y mejoras, y ese mantenimiento es parte del trato desde el principio: los primeros dos meses van incluidos como garantía, y a partir de ahí las mejoras se cotizan por hora conforme van haciendo falta.
Cada proyecto empieza con una conversación. Cuéntanos qué necesitas y valoramos juntos la mejor solución.