Practical improvement, not unnecessary complexity

Aymane Jdi did not start in a boardroom. He started installing HVAC systems.

What began as hands-on field work quickly grew into something larger. Over time, Aymane moved from installation into maintenance operations, coordinating service teams, managing preventive maintenance programs, and keeping systems running across commercial environments spanning Ottawa, Gatineau, and Montreal. He built and led an HVAC operation with real scope: emergency calls, scheduled maintenance cycles, field coordination, client expectations, and the constant pressure of keeping things running across multiple sites simultaneously.

And as the operation grew, so did a particular kind of frustration.

The technical capability was never the problem. His teams could diagnose a fault and fix it. But keeping an operation running consistently at scale was a different challenge entirely.

Knowledge lived in people's heads instead of systems. Technicians performed the same task differently depending on who showed up. Preventive maintenance findings were not always captured properly. Service reports were inconsistent: sometimes rushed between jobs, sometimes never completed at all. When recurring issues came back, tracing what had actually happened in the field was nearly impossible because the record of it barely existed.

The bigger the operation became, the harder it got to maintain consistency, visibility, and accountability across teams.

Most companies try to solve this with more paperwork, more meetings, or more supervisors.

Aymane knew that was not the answer. The problem was not effort. It was structure.

Saad Rhanmouni's world was a different kind of controlled.

After graduating from the University of Ottawa, he pursued advanced work in mechatronics and engineering management before moving into industrial R&D — developing processes in controlled environments and designing automation systems built to perform with precision. In a cleanroom or engineering lab, a process can be optimized until it is nearly perfect. Variables are controlled. Conditions are stable. The documentation is clean. The procedure works.

Then it hits a real production floor.

Saad spent years working on what is called the transfer problem: taking carefully developed processes and deploying them across overseas production lines, where those processes had to survive real operators, real shifts, and real time pressure. The challenge was never whether the process was well-designed. It almost always was.

The challenge was what happened to it after it left the lab.

Work instructions that had been carefully written were rushed during transfer and arrived on the floor incomplete. Documentation that looked thorough on paper turned out to have gaps that only appeared when a technician on a night shift tried to follow it without anyone to ask. There was no traceability. When something went wrong, there was no reliable way to trace back to where execution had deviated from engineering intent, or when, or by whom.

The process existed. The record of how it was actually being followed, or not followed, did not.

Engineering intent was one thing. Execution at scale was another.

The gap between the two was the problem.

They had met years earlier as engineering students at the University of Ottawa, both drawn to the same thing: understanding how complex systems worked and why they broke down.

After graduation, their paths split completely. One went into field operations. The other went deeper into the lab. For years, they built separate careers in what looked like entirely different worlds. HVAC maintenance operations across urban Canada on one side, robotics and manufacturing process engineering on the other.

When they reconnected, something unexpected happened.

They had been fighting the exact same problem the entire time.

From the field, the failure looked like teams doing things differently, service records that were rushed or missing, and managers chasing updates instead of leading their teams. From the lab, it looked like work instructions written once and never maintained, documentation with no traceability, and engineering intent that dissolved the moment it reached a real production environment.

Different industries. Different vocabulary. Same gap.

The real bottleneck was not capability. It was execution, specifically the lack of structure around how work was documented, followed, and verified in real conditions. SOPs that turned into PDFs nobody used. Work instructions that were rushed during handoff and never updated. No reliable way to know whether the process was being followed or where it had drifted.

Both of them had looked for a firm that understood this problem from the inside. Neither had found one that did.

That conversation became the foundation of Pixalator.