Most security software is built in one of two worlds. There is the world of the field — patrols, posts, incident reports, the specific exhaustion of a 3 AM shift — and there is the world of engineering, where that reality becomes data models, edge cases, and code. The two worlds rarely speak the same language. Trinity Guard® exists because two people spent three years forcing them to.
This is the story of that collaboration: what happens when field experience writes the requirements and engineering discipline builds the product — and, just as importantly, where the two collided.
It started with a frustration no feature list solves
I spent 26 years in law enforcement, rising from sergeant to lieutenant colonel. Somewhere in those years, the feeling set in that I wanted to build something larger than a career in uniform. Together with Gyula Györfi Jr., I founded a security company — and that is where the specific problem that became Trinity Guard® first came into focus.
The idea itself arrived somewhere between a gym session and a swim. It was not a boardroom insight; it was a practitioner's irritation. Guards did not always do what they were supposed to do. I knew this not from a study but from experience on both sides of it — I had supervised officers, and I had spent years around the private security world. I knew how patrols quietly went uncompleted, and I understood, in detail, why the traditional checkpoint hardware of the era was so easy to defeat. The industry's honor system had a technology problem, and the technology of the day was not solving it.
What was needed was almost embarrassingly simple to describe and genuinely hard to build: a patrol verification app that lived on the phone every guard already carried, that made it materially harder to fake a round, and that a guard with no technical background could actually use on a cold night without training overhead.
Describing the product took a minute. Building it right took three years.
Finding the other half of the bridge
An idea is not a company. I needed the other half of the bridge — someone who could turn field requirements into working software, and who actually wanted to.
I took meetings. Most went nowhere. Then I met Martin Szarvas, lead software engineer at Petadev Solutions. What convinced me was not a pitch deck; it was that he engaged with the actual problem. He showed real interest in the operational reality, and he came back with concrete suggestions rather than generic promises. That is a rare quality in a technical partner: the willingness to learn a domain that is not your own before proposing a solution to it.
At the end of 2022, we began building together. The division of labor was clear from the first day and has never changed. I brought the operational experience — what patrols actually are, how they fail, and what a guard will and will not tolerate. Martin brought the engineering knowledge and the development team. Neither half is sufficient alone. That is the whole point.
The friction was the feature
Here is the part most "meet the team" stories leave out, and it is the part that matters most: the collaboration worked because it was difficult.
A software engineer and a security guard do not share a level of technical knowledge, and — more importantly — they do not share a way of thinking about the same problem. That gap is not a weakness to hide. It is exactly the gap that has to be crossed for the product to be any good, and crossing it produced real, productive conflict.
The fight over simplicity.
My core requirement was a system that was capable but genuinely simple — usable by a guard, not by a developer. This was the single greatest source of friction. Engineering instinct pulls toward capability: more options, more configuration, more power surfaced to the user. Field instinct pulls the opposite way, because every additional button is another thing that fails at 3 AM in the hands of someone who was hired last week. We fought over this constantly, and the fight was worth it. What we shipped is deliberately restrained — not because we could not build more, but because the field demanded less.
That requirement has a name and a sixty-year engineering pedigree — I wrote about the KISS principle and why the simplest security systems survive separately.
The fight over deactivating shifts.
A sharper example: shift modification and deactivation. I insisted that supervisors sometimes need to modify, cancel, or deactivate a shift entirely. To the engineering mind, this looked like an edge case — why design around the exception? The team did not fully accept it on my word alone. It took a specific, real request from the security company running our beta before the necessity became undeniable. Once the field demonstrated it, the debate ended and the feature was built properly. That pattern — office skepticism resolved by field reality — repeated often enough to become the operating logic of the whole project.
This is what it actually means to say software is "field-tested." It does not mean a practitioner was interviewed once. It means a practitioner had the standing to override an engineering assumption — and the field had the final vote.
Three years, one real security company, and a working product
Concept validation did not happen in a lab. For the beta, we found a security company in Debrecen willing to run the system in live operations, and the beta testing that followed lasted nearly three years.
Three years is a long time to test a patrol app. We used all of it. Real guards, real sites, real shifts, and real consequences when a design decision that made sense on a whiteboard fell apart on a post. Every friction point above was resolved not by argument but by evidence from the field. The product reached its current form only after the two worlds had been argued out, tested out, and reconciled — over and over — in actual operation.
Why this matters to a buyer
When you evaluate a guard tour system, you are not really evaluating a feature list. Every platform in this category lists GPS, checkpoints, incident reports, and dashboards. You are evaluating whose assumptions are encoded in those features — and whether anyone with real field standing was ever in the room when the hard trade-offs were decided.
At Trinity Guard®, they were. The operational requirements came from 26 years in the field. The engineering came from a dedicated professional team. And the product exists in the narrow, hard-won space where those two worlds were forced to agree.
The platform and all of its intellectual property are owned by Trinity Guard LLC; the engineering partnership with Petadev Solutions is long-term and dedicated. Two worlds, one bridge — and a patrol verification system that reflects both sides of it.
Development partner: Petadev Solutions Kft. (Budapest, Hungary) / Petadev LLC (New York, NY). Lead engineer: Martin Szarvas. A companion piece from Martin's perspective — how the same collaboration looked from the engineering side — is forthcoming.
