Projects we delivered

Problem

A hotel chain where every property has its own reception inbox, with a general inbox above them collecting everything that goes beyond a single reception desk. Add bookings from external portals. Hundreds of emails a day – reservations, date changes, group enquiries, invoices and spam – that somebody had to route by hand between properties and departments.

How we solved it

We built a rules engine, its rule set worked out side by side with the hoteliers: the sender, the domain, the subject and the body decide where a message goes. On top of it we put an AI layer that only handles the uncertain cases and decides whether a message is a booking. Today a human only sees what genuinely needs a decision.

Problem

Returns were handled entirely by hand – the customer filed them in a boutique or through customer service, and an employee clicked through each case separately. The brand runs several independent stores, and there was no single place showing all of a customer's orders and what they are actually still allowed to return.

How we solved it

We built a self-service panel that, from an email address or a phone number, pulls a customer's orders from every Magento 2 store at once and shows what can still be returned and what cannot – because the window has closed or the parcel never arrived. We wired it to the Comarch XL system and to the InPost and DPD couriers, so the system knows the real parcel status and decides whether a return is valid on its own.

Problem

The source of truth for stock, orders and deliveries is the Comarch XL system – highly complex, with a sprawling table structure. Querying it directly from the store was risky twice over: the e-commerce code would have to know the ERP's internals, and store traffic loaded the Comarch XL database and put locks on it.

How we solved it

We built a separate data bus that absorbs all the complexity of the Comarch XL system and takes the load off its database. Synchronisation runs both ways: orders flow from Magento 2 into the ERP, and statuses, shipment data and invoices come back – we generate customer PDFs from the latter. The whole product catalogue, with prices and stock levels, travels the same route.

Problem

SAP is the source of truth for production: every product breaks down into thousands of SKUs – every screw and every component – along with symbols, permitted materials, assembly rules and prices. A store with a 3D configurator needs exactly the opposite: a finished product with a full set of options and colours, running into the millions. There is no one-to-one mapping between those two worlds.

How we solved it

We co-built an application that pulls data from the SAP system and assembles complete products out of it, with every permitted configuration, then decodes individual components into the 3D models, materials and meshes that feed the configurator. It all runs on queues – at that number of combinations, processing has to be asynchronous and built for scale rather than computed on the fly.

Problem

A company managing several buildings wanted to get rid of keycards – lost, cloned and constantly needing to be reissued. Access control lived in Modbus controllers scattered across the buildings, and employees had no single place to see their entry history or their assigned parking space.

How we solved it

We built a PWA that opens the door when an employee taps their phone against an NFC marker on the wall, talking to the Modbus controllers through our API. The same app doubles as the employee's digital badge: their details, a history of doors opened, their parking space and a people search across the company.