Pratica IOK - Connected Equipment for Professional Kitchens

Overview

Role

Project Manager / Technical Lead / Hands-On Engineer

Scope

Customer discovery, roadmap, team coordination

Timeline

Aug 2021 - Jan 2024

Highlights

• Led the execution of a connected-equipment initiative across embedded software and web application teams, coordinating five developers and a designer.
• Conducted discovery with equipment owners, operators, enterprise chain managers, internal support teams, and international distributors to identify where connectivity could solve real operational problems.
• Prioritized centralized recipe management and usage reporting as the first major capabilities, helping reduce chain-wide recipe rollouts from more than one month to less than one day.
• Supported the rollout of a connected-equipment platform that reached more than 1,500 active devices across over 30 countries.

Context

Prática is a manufacturer of professional gastronomy equipment used in environments such as restaurants, cafés, supermarkets, bakeries, and large food-service chains. As the company invested in equipment connectivity, the central product question was not simply whether its machines could be connected to the internet. It was which customer and operational problems that connectivity should solve.

Connectivity by itself would not create meaningful value. The equipment operated in demanding environments where interruptions affected food quality, service speed, maintenance, and consistency across locations. Any connected capability therefore needed to fit the realities of a working kitchen rather than behave like a technology demonstration added to the equipment.

I did not originate Prática’s connected-equipment initiative. My responsibility was to help shape and execute the product and technical path that would turn that initiative into useful capabilities for customers, operators, support teams, and distributors.

As Project Manager, Technical Lead, and a hands-on engineer, I worked across product discovery, prioritization, planning, stakeholder communication, web architecture, implementation, and team coordination. The role required connecting several different domains: embedded software running on the equipment, the customer-facing web platform, internal support workflows, hardware constraints, and the operational needs of customers using the machines every day.

Discovery

The discovery process involved several stakeholder groups with different responsibilities and different definitions of value.

Equipment owners and operators wanted better visibility into daily operations. Cleaning routines were particularly important because missed maintenance frequently led to technical problems and support requests. Some customers also wanted to compare the recipes executed by their equipment with what had been recorded by their sales systems, helping them understand stock usage, operational consistency, and possible discrepancies.

Managers responsible for multiple stores had a different challenge. Recipe lists needed to remain consistent across locations, but updating every machine was a slow manual process. A franchise chain could spend more than a month rolling out a new recipe list and still have no reliable way to confirm that every location had completed the update. These managers also wanted usage analytics showing which recipes were being executed and whether stores were operating consistently.

Prática’s support teams and international distributors needed better context before sending technicians into the field. Without access to recent equipment information, a technician might arrive at the equipment's location without the correct replacement component, tools, or understanding of the problem. Remote logs, maintenance signals, and earlier error visibility could help the support team investigate before the visit and prepare a more informed response.

Operators introduced an additional constraint: connected workflows could not interfere with active kitchen operations. An equipment update might be technically available, but installing it at the wrong moment could interrupt food preparation. Features therefore needed to respect operational pressure and keep the person using the machine in control.

These conversations shaped the product roadmap. Rather than trying to build every possible connected-equipment feature at once, we prioritized the capabilities that addressed the clearest and most frequent customer problems.

Execution

The first major direction centered on centralized recipe management and equipment usage visibility.

From the web platform, a manager could create or update a recipe list, select which equipment should receive it, and monitor whether the intended version had reached each location. On the equipment, available updates were surfaced at appropriate moments and generally waited for operator confirmation, reducing the risk of interrupting active kitchen work.

The equipment also shared usage information with the platform, allowing customers to understand how machines and recipes were being used. This created the foundation for operational reporting and gave managers visibility that had previously required manual checks or direct contact with individual stores.

We introduced the connected software gradually. The first equipment line contained four related models, and we began with the model that had the highest sales volume. After internal testing, we selected a controlled customer environment for the initial production pilot. The pilot confirmed that the product direction was valuable while also revealing issues that had not appeared during internal testing.

The first model took approximately 9–12 months from development to commercial release because the team was establishing the connectivity foundation, product workflows, and rollout process for the first time. Once that foundation had been validated, the remaining models in the same line could reuse much of the underlying work. Each of those later migrations took no more than three months, with development focusing primarily on model-specific cooking behavior and interface differences.

This first equipment line consisted of speed ovens, which are equipment used to heat pre-prepared food, that is frozen or refrigerated, quickly. We then expanded the work to a substantially different equipment line.

The next line consisted of combi ovens used for broader cooking workflows involving heat and steam. Although the connectivity foundation could be reused, the users, operating context, and product interactions were different. For the combi oven line, usage and maintenance information became especially important. The project also became a starting point for a new interface identity across Prática’s equipment.

I interviewed restaurant owners, chefs, equipment operators, and other users to understand how they interacted with each workflow. I worked with the team’s designer to explore alternatives, test them on a portable prototype using the same screen as the real equipment, and bring those options back to users for validation. The validated flows were then translated into development tasks, allowing us to test important assumptions before committing to full implementation.

The initiative was delivered through two integrated software teams. The embedded team had three developers, while the web platform team had two. A designer worked across both groups.

I coordinated prioritization, task breakdown, sprint planning, stakeholder communication, web architecture, and technical guidance, particularly for the junior developers working on the platform. I also remained hands-on, contributing wherever the teams needed additional engineering capacity across TypeScript, Node.js, React, Qt, and C++.

As the product evolved, the platform expanded beyond recipe distribution and usage reporting to include remote equipment logs, maintenance alerts, and support-oriented signals. In some situations, Prática could receive information about an equipment error before the customer contacted support, allowing the team to begin investigating proactively.

Outcome

Prática IOK turned connectivity into a practical part of the equipment experience rather than a background technical capability.

For enterprise customers, one of the clearest improvements was recipe distribution. Before IOK, rolling out an updated recipe list across every store in a chain could take more than a month, with no reliable guarantee that each location had completed the update. With the connected workflow, the rollout could happen in less than one day, and managers could monitor whether equipment was running the intended recipe-list version.

The reusable connectivity foundation also accelerated the migration of related equipment. While the first model required approximately 9–12 months to reach commercial release, subsequent models in the same line were completed in less than three months each. All four models launched commercially with connected capabilities.

By the time I left Prática, the platform supported centralized recipe updates, equipment usage reporting, remote logs, maintenance alerts, and proactive error notifications in some workflows. It had reached more than 1,500 active connected devices across over 30 countries through Prática’s existing customer base, distributors, and commercial network.

For support teams and distributors, the platform provided more useful information before field visits. Although we did not establish a measured reduction in downtime or support costs, customers repeatedly expressed that proactive contact and better-prepared technical support created a noticeably stronger service experience.

The most important outcome for me was learning how to lead a product across software and operational boundaries. Decisions made in the web platform affected embedded software, equipment operators, support teams, distributors, and customers running kitchens in different contexts around the world.

The initiative reinforced that successful connected products are not defined by the number of machines online. They are defined by whether connectivity improves a real workflow: distributing updates faster, making operations more visible, helping support teams diagnose problems, and giving customers greater confidence in how their equipment is being used.

Public Scope

This public write-up intentionally remains at the product, leadership, and customer-problem level. It does not expose customer identities, internal company data, proprietary firmware details, authentication mechanisms, private infrastructure, network flows, or critical systems architecture.

The public story is the engineering and product judgment behind the initiative: using discovery to identify where connectivity could create meaningful value, translating different stakeholder needs into a focused roadmap, coordinating delivery across embedded and web software, validating workflows before implementation, and building a reusable foundation that could expand across multiple equipment models.