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. 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. Managing distributed teams taught me that the best systems are modular - they're built to be reconfigured, not rebuilt.
Picture this - it's early 2022 and you're getting ready for another busy day at work. Everything seems normal. Then you get news that the war in Ukraine has started, and suddenly our team in Kharkiv is in the middle of a conflict zone. Our colleagues woke up to explosions and uncertainty. Vehicles were flipped over, there was gas shortages, people were fleeing. All of our staff fled across the country. Eric Sop, the CEO of UDX, was faced with a huge decision - do we carry on with business as usual, or do we stop everything to make sure they're safe?
Eric showed what true leadership looks like. He knew the safety of our team was a top priority and he acted fast. In 2023, only 350 H-1B visas were issued to Ukrainians, and only 23 in November. Yet Eric managed to secure one for Vlad, our lead developer who'd been with us for over 5 years, and his family - bringing them all to safety in Cary, North Carolina. Since then, we've had a few more people actually move to Cary. He went above and beyond by setting up security measures for our team in Kharkiv, arranging safe houses all across Ukraine, and later providing resources to keep everyone safe. UDX with Eric's leadership also supported the Ukrainian Special Forces and the government, showing that UDX really stands by its allies when it counts.
Standing With Ukraine - When Business Becomes Personal
Technology can make a real difference in the world, but it's the people behind the tech who really drive change. When Russia invaded Ukraine in 2022, we didn't just evacuate our team - we stepped up to help. UDX supported the Ukrainian Special Forces with communication equipment, helped the Kharkiv police with critical supplies, and worked with the government on cyber policy. Our team had Starlink connectivity operational before military units received their equipment.
The relationships we'd built over a decade became critical infrastructure. We worked with companies like Blackboard and Apple, helping Transact serve 17 million students by shifting them from hardware to software. That same operational discipline - the ability to move fast, adapt to changing conditions, and deliver under pressure - became essential when our Ukrainian partners needed us most. We provided medical supplies, communication gear, and the kind of support that only comes from a decade of trust.
When faced with unexpected challenges, it's crucial to act decisively, keeping resilience and empathy front and center. For us, it's all about resilience and sticking to our core values no matter what challenges we face. The experience taught me something about loyalty that no business school covers - when your team is under literal bombardment, you learn what really matters. 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. This methodology is detailed in our Deploying with Impunity framework - the operational practices that enable confident, repeatable deployments.
