Why I Joined the Marines at 19
Most people don't understand why someone would choose to enlist. For me, it was simple - I wanted to be part of something that demanded excellence. The 0656 Tactical Data program wasn't just technical training. It was a filter. Finishing first in my class wasn't about being the smartest person in the room. It was about refusing to accept anything less than complete mastery. Every day started at 0500 and ended when the work was done right. The instructors didn't care about potential - they cared about performance.
That mindset followed me to 2nd Reconnaissance Battalion, to Iraq, and eventually into every company I've built. The Marines taught me that reliable systems - whether they're communication networks or software platforms - are built by people who take ownership. No excuses, no ambiguity, no almost. When you're responsible for data operations in a combat zone, there's no room for "good enough." Every packet matters. Every connection has to work. That discipline became the foundation for everything I've built since - from enterprise platforms processing billions in transactions to distributed teams operating across three continents.
The military also taught me something about leadership that most business schools miss entirely. Real leadership isn't about having the answers - it's about creating environments where your team can find them. It's about setting standards so high that mediocrity becomes uncomfortable. And it's about taking responsibility when things go wrong, not just credit when they go right.
Landing Lockheed Martin as Client Number One
When I founded UDX in 2011, I had one goal - prove that a veteran-owned small business could deliver at the highest levels of enterprise complexity. Lockheed Martin became our first client. We built their SBIR/STTR solicitation platform, and that project taught me more about enterprise delivery than any certification ever could. The defense industry doesn't tolerate excuses. Every deliverable has a deadline, every system has to work the first time, and every failure has consequences that extend far beyond a missed sprint.
The lesson was clear - large organizations don't need more vendors. They need partners who understand that their problems are complex, their stakeholders are many, and their tolerance for failure is zero. That's the standard we've maintained across every engagement since. Working with Lockheed taught me how to navigate procurement processes, manage security clearances, and deliver solutions that meet both technical requirements and compliance mandates.
That first contract opened doors across the defense sector. We went on to work with Northrop Grumman, support Marine Corps logistics systems, and build platforms that handle sensitive government data. The pattern was always the same - understand the mission, deliver on time, and never compromise on security. Those principles became the foundation of everything UDX does today, whether we're building for defense contractors or enterprise software companies.
Building Teams Across Three Continents
In 2012, I opened our Ukraine office in Kharkiv. The talent in Eastern Europe was extraordinary, and over the next decade we built a network of over 200 partners across the region. Managing distributed teams taught me that the best systems are modular - they're built to be reconfigured, not rebuilt. We had a two-floor building in Kharkiv, a growing team of engineers, and a pipeline of projects that kept everyone busy. The time zone difference actually worked in our favor - we could hand off work at the end of the US day and wake up to completed deliverables.
When Russia invaded in 2022, everything changed overnight. Our team had Starlink connectivity operational before military units received their equipment. We evacuated people, helped families get to safety, and navigated visa processes where only 1 in 10 applicants even get a chance. The relationships we'd built over a decade became critical infrastructure. Two of our team members are still in Ukraine, continuing to work while their country fights for survival.
The experience taught me something about resilience that no business school covers. When your team is under literal bombardment, you learn what really matters. You learn that the systems you build need to work when everything else is falling apart. You learn that loyalty isn't just a corporate value - it's a commitment you make to the people who trusted you with their careers. That's the standard I hold for every team I build now, regardless of geography.
The First Digital Campus ID for Apple Pay
In 2018, Blackboard contracted us to build something that didn't exist yet - a digital campus ID system for Apple Pay. Duke University would be the launch partner. The technical challenge was significant, but the real complexity was meeting Apple's standards while integrating with legacy campus infrastructure. Every campus has decades of accumulated systems - door access, meal plans, library services, parking - and they all need to work seamlessly with a digital credential that lives in a student's iPhone.
We built it. The system now serves over a million students across hundreds of campuses. Apple recognized our work as setting the standard for digital logistics among their payment partners. It proved that cloud-native architecture could handle enterprise-scale transactions without compromising security or reliability. The integration had to be bulletproof - when a student taps their phone to open a dorm door at 2 AM, there's no room for "service unavailable."
The project changed how I think about scale. Processing millions of transactions isn't just about throughput - it's about consistency, auditability, and graceful degradation. When you're handling $65 billion in tuition payments annually, every edge case matters. The patterns we developed for Apple Pay integration became the foundation for everything we've built since - from payment processing to identity management to real-time synchronization across distributed systems.
Why Alignment Beats Automation
The most expensive bugs aren't in the code - they're in the misalignment between systems. Court numbering that doesn't match the reservation system. Membership tiers that sync differently between website and backend. Booking types that look identical when they should be visually differentiated. These mismatches create customer confusion that no amount of automation can fix. I've seen companies spend months building integrations only to discover that the fundamental data models don't agree on what they're tracking.
Before building any integration, I validate alignment at every touchpoint. Does the website show the same court numbers as the physical facility? Do membership prices display consistently across all platforms? Are online bookings visually distinct from walk-in reservations? Get the alignment right first. The automation becomes trivial once the systems actually agree on what they're tracking. This validation phase catches problems that would otherwise surface as customer complaints months after launch.
The pattern applies beyond software. When I'm advising organizations on infrastructure decisions, the first question is always about alignment. Are your staging environments actually representative of production? Do your service accounts have permissions that match their intended scope? Is your Terraform state consistent with what's actually deployed? Misalignment compounds over time. The earlier you catch it, the cheaper it is to fix. That's why I always start with a manual validation phase before automating anything.
Ship Manual First, Automate Later
The instinct is always to automate immediately. But I've learned to resist it. When launching a new membership platform, we start with manual member creation and payment synchronization. When integrating a new reservation system, we manually validate each booking type before connecting the APIs. The manual phase reveals edge cases that automation would have hidden. You discover that certain membership tiers have special pricing rules, or that some booking types need different confirmation workflows, or that the data model assumptions don't match reality.
This approach extends to infrastructure. Environment-specific service accounts instead of generic credentials that sprawl permissions. Terraform-first provisioning so every resource is declared and reproducible. Workload identities that limit permissions to exactly what's needed. Prove the workflow works manually, document the edge cases, then automate with confidence. The time you spend in the manual phase pays dividends when your automation doesn't break in production because you already knew about the weird edge cases.
The Marine Corps taught me this discipline. Before any operation, you rehearse. You walk through every step manually. You identify the failure points. You build contingencies. Only then do you execute. The same principle applies to software. Ship manual first, learn what actually happens, then automate what you've proven works. It's slower at the start, but it's faster in the long run because you're not debugging automation that was built on false assumptions.
