Building Trinity Guard: Turning Real-World Security Experience Into a Digital Patrol Platform

Client: Trinity Guard
Industry: Physical Security
Engagement: Product strategy, mobile and web development, backend, cloud infrastructure, AI, ongoing development and go-to-market support
Started: Late 2022

In late 2022, Gyula Györfi found Petadev through a Google search.

He didn't come to us with a finished specification, a set of wireframes or even a final product name.

He came with a problem.

After 26 years in law enforcement and further experience in private security, Gyula knew how security operations worked in practice, including the ways patrol-control processes could fail when the system relied too heavily on trust or easily manipulated checkpoints.

One example he had seen firsthand involved traditional physical checkpoint systems. A checkpoint could be removed from its intended location and brought back to the guard booth, making it possible for a patrol record to appear complete even though the route itself had never been walked.

And this wasn't a theoretical edge case. It was the kind of workaround other people in the industry complained about as well.

Gyula's original idea was still early-stage, but the objective was already clear:

build a digital patrol-control system that gives security companies a much clearer picture of whether assigned rounds are actually being completed, without forcing them to invest in another category of dedicated hardware.

That early idea eventually became Trinity Guard.

He knew the security problem. We had to turn it into software.

There was no complete product specification when the project started.

We knew the main functional areas Gyula wanted to address, but turning those ideas into an MVP meant working through the operational details together.

That distinction matters.

“Make sure the guard completes the patrol” is a perfectly understandable business requirement.

It is not yet a software requirement.

To build something around it, we had to turn Gyula's operational knowledge into questions the system could answer.

How should physical presence be verified?

What happens when GPS accuracy changes between open outdoor areas and enclosed buildings?

How should patrol routes, guards and shifts relate to one another?

What information does a guard need on a phone, and what does a supervisor need to see from a browser?

How should exceptions be handled when real life does not follow the planned route?

The final MVP specification came out of that process.

Gyula did not have to become a software architect, and we did not pretend to know private security better than someone who had spent decades working in it.

The product came from combining those two perspectives.

The first version focused on the operational core

From the beginning, Trinity Guard was designed as two connected applications.

The mobile app is used in the field. The web application gives supervisors and administrators the tools to plan and oversee the operation.

The first version centered on the core problems Gyula had brought to us: location-based patrol tracking, duty and shift scheduling, internal communication and operational export functions.

One product decision influenced almost everything that followed:

a smartphone should be enough to use the system.

Traditional guard-tour setups can require proprietary readers or dedicated patrol devices. That adds purchasing, deployment and maintenance overhead before a security company can even start using the system.

Trinity Guard took a different approach.

The guard already carries a capable mobile device. We used that device as the field interface and built the rest of the operation around it.

The result was not simply a digital replacement for a checkpoint wand. It became a connected system in which field activity, scheduling and management could share the same data.

GPS worked outdoors. Indoors was a different problem.

Location-based verification gave us a useful tool for outdoor patrols.

Inside buildings, the situation changes.

Underground parking garages, warehouses, stairwells and other enclosed spaces can make GPS inaccurate or unavailable. A patrol system that relied exclusively on satellite positioning therefore could not reliably cover many of the places guards actually need to check.

We later introduced QR-based indoor checkpoints.

The concept was straightforward: install a unique QR marker at the checkpoint and let the guard scan it with the same smartphone already used for the rest of the system.

That solved the indoor location problem.

It also created a new verification problem.

A photograph of a QR code should not be treated the same as the QR code on the wall

A QR code can be photographed.

If a system only checks whether the code itself is valid, a photograph can potentially produce the same result as scanning the physical checkpoint.

In other words, we had recreated a digital version of the original problem Gyula had described at the beginning of the project.

Moving the checkpoint was no longer necessary.

A copy of it could travel instead.

This is where Trinity Guard became technically much more interesting.

Rather than adding another piece of hardware or relying on GPS in an environment where GPS was already unreliable, we started working on the scan itself.

We trained our own neural network on tens of thousands of images

We developed and trained a custom neural-network model using tens of thousands of images.

Its purpose is to identify visual patterns that can indicate when the system is seeing a photographed representation of a QR checkpoint rather than the original physical marker.

That distinction is deliberately important.

The model does not act as a judge and automatically accuse a guard of fraud. It provides an additional verification signal that can be surfaced to supervisors when a scan appears suspicious.

This makes the system harder to manipulate without adding a proprietary reader, changing the guard's normal workflow or relying on indoor GPS.

It is also a good example of how we approach AI development.

We did not add an AI feature because the product needed an “AI” label.

A specific operational problem appeared, conventional approaches came with significant compromises, and machine learning provided another way to address it.

Trinity Guard kept evolving because the real world kept producing new requirements

The first release was only the beginning.

As the platform entered actual security operations, we continued developing it based on real usage, new markets and new business requirements.

Indoor QR patrol verification was one major step.

It was followed by a broader set of capabilities around site operations, onboarding, payments and AI.

Trinity Agent made years of operational data easier to understand

As the amount of patrol and site data grew, supervisors faced another practical problem.

The information existed, but finding the useful part could still mean digging through a large amount of history.

We developed Trinity Agent as an AI-assisted interface over that operational data.

A user can ask about activity at a particular site, and the system can process relevant history and records to produce a summarized view of what has been happening.

The underlying logs remain the source of truth. The AI layer makes them faster to navigate and understand.

For security managers responsible for multiple locations, that can remove a significant amount of repetitive review work.

We also helped turn the software into a scalable product

Our work with Trinity Guard has gone beyond writing the mobile and web applications.

As the product matured, we also helped develop the systems needed to bring it to market more efficiently.

The web application received improved onboarding. Registration and card payments became automated, allowing new customers to sign up and start using the service with less manual involvement.

We added access-management functionality for environments where security personnel also need to register people, vehicles, deliveries or other site entries and exits.

The platform was localized for multiple markets and now operates in several languages and regional variants, including Hungarian, Serbian, Polish, English, Spanish and Portuguese localizations.

Today, Trinity Guard is used across multiple regions, including Europe, the United States, South America and Africa.

For the U.S. market, the same platform is also presented through the Digital Guard Tour marketing brand.

The infrastructure behind running and synchronizing a platform across different regions eventually became a substantial engineering challenge of its own.

That deserves a separate case study.

Petadev built the entire technology stack

Trinity Guard was not a project where we were responsible for one isolated component.

Petadev built the platform from the ground up.

That includes the mobile application, web application, backend services, cloud infrastructure and later AI functionality.

As the product developed, our involvement also expanded into go-to-market support and SEO, helping the technical product and its market presence evolve together.

This matters because decisions in one part of a platform almost always affect the others.

A mobile workflow changes backend requirements. A subscription model changes onboarding and billing. International expansion changes infrastructure and localization. AI features depend on what data the product has been collecting.

Treating those as one connected product rather than a collection of unrelated development tasks made long-term evolution much easier.

What made the collaboration work

The strongest part of the Trinity Guard project was not a particular framework, AI model or cloud service.

It was the division of expertise.

Gyula knew the industry.

He understood what guards actually did on a night shift, how supervision worked, where conventional processes failed and what kinds of shortcuts people found when a system could be bypassed.

Petadev knew how to turn those realities into product logic.

Our job was to ask the technical questions, identify the constraints, design the architecture and build a system that could translate those operational requirements into software.

That is a very different relationship from receiving a finished specification and implementing it screen by screen.

It also explains why the system changed so much after its original launch.

Real users exposed problems that no initial document could have fully anticipated.

Every one of those problems became new product knowledge.

From one operational problem to an international platform

The original idea behind Trinity Guard was relatively focused:

make security patrols more transparent and harder to manipulate without requiring dedicated patrol hardware.

The product today goes much further.

It combines mobile patrol tools with web-based scheduling and administration, indoor and outdoor verification, communication, operational records, access-management features, subscription management and AI-assisted functionality.

And it continues to evolve.

That development history is probably the most important part of the case study.

Trinity Guard did not begin as a detailed specification for a large software platform.

It began with an experienced person explaining:

“This is what keeps going wrong in my industry.”

The software came afterward.

“I recommend Petadev. They are a reliable, conscientious team and, just as importantly, they know what they're doing. If you want an app that works and looks good, choose them.”
 Gyula Györfi, Trinity Guard
Translated from Hungarian

Domain knowledge is often more valuable than a finished software specification

Founders sometimes approach us worried that they do not know enough about software.

Trinity Guard is a good example of why that is not necessarily a problem.

You do not need to arrive with database architecture, API documentation and 80 finished Figma screens.

If you have spent years in an industry and understand a problem deeply, you already have something a development team cannot manufacture on its own.

You know where the process breaks.

You know what users actually do rather than what the procedure manual says they do.

You know which workarounds have already failed.

You know what information would make the business easier to operate.

Our role is to translate that knowledge into a product that can actually be built, used and developed further.

That was the starting point of Trinity Guard.

And it is often the starting point of the most interesting custom software projects we work on.