About Rick
I grew up in Silicon Valley before people called it Silicon Valley. In the mid-1960s computers filled rooms, not desks.
By the late 1970s I was already hooked on technology — I was the first kid on my block with the original Pong console.
Through a school teacher who knew the founder, I even visited Atari’s employee game room. That was my first exposure to the idea that software didn’t just automate work — it could create entirely new experiences.
In high school in Santa Clara, California, I split my time between electronics labs and early programming classes. Back then you didn’t learn an app — you learned how systems actually worked: circuitry, logic, memory, and control flow. That mindset shaped everything that followed.
Learning computing when failure actually mattered
In 1985 I joined the United States Navy. At the time computing still relied on punch cards, paper tape, and OCR scanning — reliability wasn’t theoretical. If systems failed, operations stopped.
I became a certified systems administrator responsible for shipboard logistics and financial platforms including the Shipboard Uniform Automated Data Processing System (SUADPS), which managed operating funds (OPTAR) and tracked supply distribution across fleet operations. I served on a special accounting class-207 vessel where we effectively operated with a government “blank checkbook.” Every part ordered had to be traced to its receiving unit and reconciled with transferred funds — accuracy was operational accountability.
I later worked on the Navy’s SNAP I & II modernization initiative, converting paper-based administrative and maintenance processes into microcomputer systems. That work required translating real-world operational behavior into reliable digital systems long before the phrase “digital transformation” existed.
Human systems: the earliest security lessons
During my Navy service I also held an unusual operational support role known as an expeditor.
The job existed to remove logistical friction — when critical parts or supplies were stalled somewhere in the defense supply chain, we were responsible for getting them moving again.
In the mid-to-late 1980s this meant working almost entirely over the phone, including secure STU-3 communications, contacting both military and civilian personnel supporting operations.
I was trained by an exceptionally skilled communications specialist whose focus was not technology, but people — voice control, confidence, context framing, and understanding how humans make decisions under pressure.
The techniques relied on persuasion, credibility, and identity presentation rather than authority alone. The goal was always legitimate — support fleet operations — but the methods required understanding how individuals interpret trust, urgency, and authenticity.
I eventually developed my own approach to the role and never failed a mission request during my assignment and was awarded the Navy Achievement Medal after my last deployment that included time in Diego Garcia and Karachi Pakistan.
That experience became my earliest exposure to what would later be called social engineering. It taught me that systems rarely fail first at the hardware or software layer — they fail at the human expectation layer.
Security isn’t only about protecting machines. It’s about understanding how people decide what to trust.
Operating where there are no manuals
Later in my service I was selected to support a classified small-unit operational team. Because of the sensitive nature of the work the technical specifics can’t be discussed publicly, but the environment can: small teams, overlapping responsibilities, incomplete information, and real consequences for bad assumptions.
The assignment became my first exposure to the early web and HTTP-based systems, intelligence workflows, and analytical tooling. I also worked with emerging digital media techniques — including early image analysis and manipulation — at a time when these technologies were still new in operational environments.
The team frequently collaborated with highly specialized personnel, including top-tier operators and inter-agency partners. Tasks sometimes originated directly from command leadership and senior enlisted leadership, but the work was always discreet in nature. There were rarely documented procedures — you analyzed the situation, applied technical reasoning, and built solutions from what was available.
My systems, logistics, and computing background proved valuable because the problems didn’t fit a single discipline. The work demanded cross-domain thinking, improvisation, and decisions you could stand behind. During this assignment I was awarded the Navy and Marine Corps Commendation Medal, and the unit received a Meritorious Unit Citation.
Systems must work in imperfect conditions — especially when the environment itself is uncertain.
Responsibility beyond technology
After my time supporting classified operational units I was offered an assignment involving electronic intelligence collection at Naval Security Station Sugar Grove. Instead, I accepted a very different challenge — an IT support role at a Naval Corrections Unit which would allow me to spend more time with my 2 sons who hadn't seen me very often in my previous role.
The position required becoming a certified military corrections officer through training at Lackland Air Force Base, in addition to serving as the unit’s sole IT specialist. I supported logistics and financial staff, supervised civilian administrative personnel, and maintained all technical systems the facility depended on.
Technically, the environment reflected the era: a Novell NetWare 3.11 file server running on a token-ring network supporting roughly thirty Windows 95 workstations. These were internal networks long before internet-connected security tools existed. My earliest exposure to computer security issues came from handling early Microsoft Office macro viruses — incidents the senior chief would routinely call me in to help diagnose and clean.
The role did not stop at technical support. I also stood watch on the cell block and handled detainee situations when required. It was an environment where technical decisions affected people directly and immediately, not just systems.
Managing operational duties, corrections responsibilities, and technical systems simultaneously required constant prioritization and accountability. For successfully handling these overlapping roles, my tour was extended an extra year and I was awarded the Navy Achievement Medal.
My first cybersecurity lessons didn’t come from the internet — they came from isolated networks where you had to understand both the machines and the humans using them.
Two lives: Healthcare IT, cybersecurity & continuous building
For the last 21 years I’ve worked in Healthcare IT at a innovative and quickly growing healthcare system. My roles evolved from helpdesk support to desktop and solution engineering — working with SCCM, Group Policy, and Active Directory — and eventually into software development for the last decade across multiple application stacks.
Enterprise healthcare environments operate under strict uptime, auditability, and compliance requirements. That experience shaped how I approach production systems: conservative change control, observable behavior, and automation that must be explainable — not just functional.
In parallel, since 2009 I’ve independently studied cybersecurity and adversarial behavior. I completed the TryHackMe Junior Penetration Tester learning path and numerous hands-on attack and defense labs. The goal was not to become a full-time pentester, but to understand how real attackers think, probe systems, and discover weak signals before alerts exist.
This offensive perspective fundamentally changed how I design monitoring. Instead of only tracking system health, I began focusing on behavior patterns — reconnaissance activity, enumeration attempts, and the subtle pre-attack indicators that traditional monitoring rarely surfaces.
For more than 30 years I’ve effectively lived two technical lives: a professional enterprise career maintaining mission-critical systems during the day, and nights and weekends spent building startups, experimenting, and shipping software. It isn’t glamorous — it’s long hours and constant learning — but it produces practical engineering judgment.
SiteSpy exists at the intersection of operations engineering and attacker mindset: reliability from the operator’s side and visibility from the adversary’s side.
Building things outside the job description
After military service I continued across technical roles and helped launch about five startups. Most of them solved practical operational problems: automation, integration, and information visibility.
Across decades — mainframes → client/server → web → cloud — one pattern stayed constant: organizations rarely lack data; they lack visibility into what is actually happening.
Why I built SiteSpy
SiteSpy was born from the operational insight that monitoring focused only on uptime misses the real risks. Outages are obvious; silent failures, behavior drift, and partial breakage are not.
SiteSpy watches systems the way operators do: not just Is it online? but Is it behaving correctly?
The product combines decades of reliability thinking with modern web infrastructure to give teams the visibility they need to make confident decisions.
Perspective
I’ve lived through nearly every era of computing — arcade hardware, mainframes, naval operational systems, early microcomputers, enterprise software, the web, and cloud platforms. Tools changed; the core problem didn’t: people need trustworthy information to act. That’s what SiteSpy is designed to provide.
