Sobre Emyrix
Emyrix LLC es una empresa de desarrollo de software y web con sede en Massachusetts. Construimos y mantenemos aplicaciones web, sitios web y plataformas de e-commerce: aplicaciones a medida en Laravel y React, sitios en WordPress y WooCommerce, y tiendas en Magento, Adobe Commerce y Shopware.
Magento y Adobe Commerce son donde nuestra experiencia de plataforma es más profunda, pero el trabajo de fondo es más amplio que una sola plataforma: entender el software que ya existe, construir las partes que faltan y mantenerlo rápido y seguro una vez que está funcionando.
Nuestro enfoque
Los problemas suelen ser los mismos tanto si la aplicación es una tienda, un sitio en WordPress o un sistema interno de negocio: dependencias antiguas, propiedad poco clara, consultas lentas, integraciones que fallan en silencio y código que se ha vuelto difícil de cambiar sin riesgo.
aplicaciones web a medida en PHP, Laravel y React: portales de clientes, herramientas internas, paneles, APIs y las capas de integración entre sistemas que nunca se diseñaron para hablar entre sí. Parte de eso es trabajo nuevo. Una buena parte es PHP antiguo que tiene que seguir funcionando mientras se pone al día.
Sitios en WordPress y tiendas WooCommerce, temas y plugins a medida, integraciones, y el trabajo de rendimiento y seguridad que los mantiene fuera de problemas. Buena parte consiste en recoger un sitio cuyo desarrollador o agencia original desapareció hace tiempo. Y si WordPress no encaja con lo que nos describe, se lo diremos antes de que nadie lo construya.
Magento es la plataforma que mejor conocemos. Trabajamos con Magento Open Source, Adobe Commerce y Mage-OS: proyectos nuevos, actualizaciones de versión, parches de seguridad, migraciones a Hyvä, B2B, módulos a medida y el trabajo de rendimiento que mantiene rápidos los catálogos complejos. Mucho de esto empieza heredando una tienda y devolviéndola a un estado en el que publicar cambios sea rutina y no riesgo.
Cómo trabajamos
Intentamos resolver los problemas de forma que el siguiente cambio sea más fácil. En Magento eso significa plugins, inyección de dependencias y service contracts en lugar de editar el core, para que las actualizaciones y los parches se apliquen limpiamente en vez de pelearse con las personalizaciones. En Laravel y WordPress significa mantener la lógica de la aplicación fuera de los sitios que una actualización va a sobrescribir, y mantener el trabajo a medida en control de versiones en lugar de editado directamente en el servidor. El trabajo se perfila antes de optimizarlo, se prueba antes de publicarlo y se documenta lo suficiente para sobrevivir a la siguiente actualización o a la siguiente contratación.
La mayoría empieza con un problema: un sitio que se puso lento, una aplicación que nadie quiere tocar, una publicación bloqueada, o un sistema nuevo que tiene que hablar con uno antiguo. A partir de ahí acotamos el trabajo en una secuencia práctica y acordamos qué significa el éxito antes de tocar código, y después seguimos ahí mientras el sistema sigue cambiando.
Experiencia técnica
Experiencia
Esa experiencia viene sobre todo de proyectos de e-commerce, y por eso la lista de abajo va en esa dirección. Los problemas de ingeniería de fondo suelen trasladarse a otros tipos de aplicaciones.
Tiendas omnicanal y directas al consumidor, pensadas para navegar y comprar rápido.
Cuentas de empresa, precios por niveles, presupuestos y flujos de aprobación.
Comercio conectado al ERP y productos configurables.
Búsqueda por compatibilidad, catálogos de piezas y datos de producto complejos.
Merchandising cuidado, variantes y storefronts rápidos.
Tratamiento cuidadoso de la seguridad, la privacidad y las normas de cumplimiento.
Quién está detrás de Emyrix
Emyrix es propiedad de Darwin y la dirige él, un ingeniero full-stack sénior que escribe PHP desde 2006 y trabaja con Magento desde 2016: unos cuatro años en empresa y después seis en dos agencias. Su titulación es en ingeniería, y se certificó como desarrollador frontend de Magento cuando ese examen todavía se correspondía con la plataforma.
Buena parte de esa trayectoria ha consistido en hacerse cargo de software que construyó otra persona. Es un trabajo distinto a empezar de cero: hay que entender lo que hay antes de decidir qué debe cambiar, y suele ser la situación en la que está quien nos escribe.
El trabajo técnico se mantiene cerca de quien toma las decisiones. El alcance sale de alguien que lee el sistema real, no de una descripción que ha pasado por dos capas de gestión de cuentas, y la estimación sale de quien tiene que cumplirla.
Trayectoria
Buena parte del trabajo ha sido Magento, tanto Magento Open Source como Adobe Commerce, incluido Adobe Commerce on Cloud. Eso cubre tiendas a lo largo de las versiones 2.x, con actualizaciones de versión, parches de seguridad, funcionalidad B2B, frontends en Hyvä, módulos a medida y las integraciones que conectan una tienda con el resto del negocio.
Esa experiencia importa más allá de Magento. El e-commerce tiende a sacar a la luz las partes del desarrollo de software que es fácil subestimar: datos complicados, catálogos grandes, sistemas externos, procesos en segundo plano, reglas de pago y envío, y aplicaciones que tienen que seguir funcionando cuando sube el tráfico o el volumen de pedidos.
Antes del trabajo de e-commerce, y en paralelo, hubo aplicaciones internas construidas sobre Zend Framework 2 y Laravel.
Uno de esos sistemas gestionaba datos de producto y publicaba listados en Amazon, Walmart, eBay y otros marketplaces desde una única fuente. Otras aplicaciones eran herramientas internas, sistemas de administración y capas de integración.
Laravel ha seguido siendo parte del trabajo desde entonces, incluidas aplicaciones construidas fuera del e-commerce. Es parte de por qué Emyrix trata una aplicación web como software y no simplemente como un conjunto de páginas.
No todo lo que necesita ingeniería es una plataforma de comercio.
Algunos proyectos son sitios web. Algunos son instalaciones de WordPress que llevan años funcionando y necesitan limpieza, seguridad o velocidad. Otros son aplicaciones internas que se le han quedado grandes a la persona o al equipo que las construyó.
Mucho del trabajo de agencia consistió en heredar sistemas sin documentar o que habían pasado por varios desarrolladores con el tiempo. Eso crea una costumbre útil: leer lo que hay antes de decidir qué debería reemplazarlo.
A veces la respuesta correcta es reconstruir. A menudo no lo es.
Una tienda, un sitio web o una aplicación rara vez son el sistema completo.
Los productos pueden venir de un ERP. Los pedidos pueden ir a un sistema de fulfillment. Los datos de cliente pueden vivir en un CRM. Los marketplaces necesitan feeds. Pagos, envíos, impuestos, búsqueda, correo e informes tienen cada uno sus propios requisitos.
Una parte considerable del trabajo de ingeniería ocurre entre esos sistemas: hacer que los datos se muevan de forma fiable, gestionar los fallos cuando no lo hacen, y asegurarse de que alguien se entera cuando algo ha dejado de funcionar.
El mismo trabajo aparece en Magento, Shopware, WooCommerce, WordPress, Laravel y aplicaciones a medida.
La mayor parte del trabajo de comercio ha sido en piezas de automoción, suministro científico y de laboratorio, dispositivos médicos, artículos de regalo y retail especializado. Esas tiendas tienden a compartir los mismos problemas: complejidad de compatibilidad y atributos entre miles de SKUs, reglas de impuestos y envío que cambian por producto, búsqueda que hay que ajustar y no solo activar, y feeds de ERP o de marketplace que se rompen en silencio cuando nadie los está mirando.
Por qué trabajamos así
Se aprende rápido que la solución más limpia a la vista no siempre es la correcta, que un cambio pequeño puede tener un alcance sorprendentemente grande, y que la documentación importa sobre todo cuando quien escribió el código ya no está.
Así que empezamos por entender lo que ya hay, medimos antes de cambiar nada por velocidad, probamos los cambios antes de que lleguen a nadie más, e intentamos dejar el sistema más fácil de trabajar de como lo encontramos.
Trabajemos juntos
Cuéntenos qué intenta construir, qué no está funcionando o qué ha heredado. Lo miraremos y le diremos qué haríamos a continuación.