Outmatic
Why Outmatic
The engineering partner for the AI era.
Real context first, then the right technology, not the other way around.
Read our storyOutmatic
A custom Permit to Work platform for an Italian industrial group with multiple plants. Faster operations, fewer errors, and a mobile signature that took hours out of the daily cycle.
Outmatic
Engineering Team
Tampieri runs industrial operations that touch very different worlds: vegetable oil processing, renewable energy generation, wastewater treatment, specialty materials, and agricultural trading across Italy and Eastern Europe. Different as they are, these businesses share one thing: they happen inside real industrial sites, where work permits are part of the daily operational rhythm. Who can do what, where, and under which conditions, is not a formality. It's a safety-critical process.
Until recently, that process lived between paper, spreadsheets, and partial tools, with the limits you'd expect from a workflow that was never really designed. The company wanted to move it onto a single, custom system. Something fast enough for daily shift use, structured enough to guarantee traceability, and flexible enough to serve different sites, roles, and languages without forcing everyone into the same template.
Tampieri chose Outmatic for this work based on our track record with Permit to Work solutions in industrial environments, where safety, traceability, and day-to-day usability all have to hold at the same time.
The project started with a shared analysis phase together with the Tampieri team, to define requirements, flows, and operational priorities before any code was written.
The existing setup had the typical issues of a process that had grown organically: manual or fragmented steps with limited traceability, the need to cover different languages and sites with differentiated roles and permissions, performance expectations high enough to survive daily shift use, and the need to guarantee stability from the first release onward.
The real challenge was designing a system that handled all of this without feeling heavy to the people who actually use it every day on the plant floor.
We worked in close collaboration with the Tampieri team from the very first workshops, shaping requirements and architecture together. The approach was iterative: design, release, listen, adjust.
From concept to architecture, we picked a stack that gave us scalability, maintainability, and performance without introducing complexity for its own sake.
React for the front-end, to build a reactive, modular UI that would feel fast during daily use.
.NET for the back-end, structured around microservices so that responsibilities stayed separated and releases could move independently.
MongoDB as the database, because permit types vary site by site, with their own attributes and variants. A document model handled that reality better than forcing everything into a rigid schema.
AWS as the cloud platform for the entire deployment, giving us a scalable, reliable foundation that could serve multiple sites without infrastructure becoming a bottleneck.
Alongside the build, we set up an automated test suite (unit, integration, regression) from the earliest iterations. Not as an afterthought, but as a foundation. The system would need to evolve for years, and tests are what make that evolution safe.
The workshops were the foundation of everything else. Sitting with the people who actually issue and approve permits on the floor surfaced edge cases that no requirements document would have caught: site-specific rules, informal escalation paths, exceptions that existed because nobody had ever written them down.
From there, the work moved in short iterations. We released core functionality in modules and validated each one with the Tampieri team before moving on. The microservices architecture meant we could ship one part (say, the approval workflow) without waiting for another (the reporting layer), which kept momentum visible throughout the build.
One of the core pieces we designed was mobile signature: permits can be approved and signed directly from phones and tablets, right where the work happens. For a process that used to require moving papers between offices and the plant floor, this alone took hours out of the daily cycle and made traceability immediate.
The automated test suite ran alongside every iteration. By the time the first version reached production, we already had a safety net in place for the evolution that would follow.
Rollout was controlled. The platform went live on one site first, with close support during the initial weeks, before extending to the rest of the group. Running on AWS made that progression smooth: no infrastructure surprises, consistent performance across sites, and room to scale as adoption grew.
The shift worth noting isn't in the numbers. It's that the system moved from being a project to being the tool people use every shift.
The lesson from Tampieri is narrower than it sounds. When a process is safety-critical and lives across different sites, a generic platform won't fit, and a custom build only pays off if it's designed to be maintained, not just delivered. The stack choices mattered, but the decision that made the difference was setting up the test suite from day one. It's what turned the first release into a system the client can keep evolving without fear.
The project also confirmed something we already knew from previous engagements: Permit to Work is a domain where small design decisions have outsized consequences. Getting the interaction model right for people on the plant floor is the part most projects underestimate.