M&T narrative draft

M&T why dual · Updated Jul 22, 2026 10:06 PM · Selection: M&T essay arc

Linked projects

Stux Technologies — CTO & Founder — Founded and lead Stux Technologies, building web platforms and AI-powered automation for NYC investm
UPRS Group — Lead AI Developer, Financial Systems — Designed and built UPRS Group’s web platform (uprsgroup.com) with document uploads, contact/asset ma
PARKLYO — Founder (iOS App Store) — Created PARKLYO, an App Store iOS app to pin anything in the real world — parking spots, seats, bags
Yad L'yad — Founder & Educator (STEM / Prosthetics) — Organized and led a STEM club with a hands-on curriculum. Led workshops designing and assembling DIY
Bionic Arms — Low-Cost Articulated Prosthetic — Designed and 3D-printed a fully articulated prosthetic arm exploring biomechanics, CAD, and accessib
ValedictAI — AI Study Platform — Built an AI-powered study platform for personalized tutoring, study-session tracking, and document w
BioCap — Milk Freshness Sensor — BioCap is a conductivity-based milk freshness sensor that measures what’s actually in the carton — n

Title

Content

# Why M&T: Building Systems That Ship Into the Real World

I don't want to learn engineering *or* business. I need both in the same loop—because the products I build only matter when they solve real problems for real organizations, under real constraints.

---

## The Pattern: Technical Depth Meets Organizational Reality

**Stux Technologies** made this clear. I'm the CTO and founder, building AI-powered automation for NYC investment firms and banking institutions—systems that turn hours of manual data collection, client outreach, and document processing into minutes. Our healthcare automations now support 10,000+ patients nationwide, and we serve institutional clients managing over $1 billion in assets.

But here's what matters: I didn't just write code. I had to understand *workflows*—how analysts actually spend their day, where compliance sits, what "five minutes faster" means when you're managing a portfolio or coordinating patient care. Building for regulated industries taught me that reliability, confidentiality, and measurable time-savings beat flashy demos. The technical systems (Python backends, AI pipelines, financial data platforms) only create value when they fit into an organization's operations and trust model.

Leading a team while shipping taught me to scope automation around real workflows, not abstract AI capabilities. That's not a skill you learn in a CS lab or a business case study—it's the integration of both.

---

**UPRS Group** reinforced this. As Lead AI Developer, I built their full-stack web platform—document uploads, contact/asset management, internal workflow tools, Python automation for research and PDF processing. The backend ran on DigitalOcean with reference-number client lookups; the frontend had to serve both external clients and internal ops teams.

Financial services workflows are messy and high-stakes. The win wasn't a static brochure site—it was connecting a client-facing interface to real internal databases and automations. I had to think like an operator: What does compliance need? How does this fit their existing process? What happens when the system is down? Pure engineering gives you the platform; business judgment tells you what to build and how to deploy it so people actually use it.

---

## When Engineering Needs an Organizational Wrapper

**Yad L'yad** showed me that even hardware has to ship through a system. I founded and led a STEM club, organizing workshops to design and assemble DIY prosthetic hands for children in a Kenyan refugee camp—many living with limb loss from conflict and limited medical access. Fifteen children wrote independently for the first time, supporting their continued education and long-term independence.

The engineering—3D-printed fingers, tendon-driven articulation—was only half the problem. Curriculum design, materials logistics, teaching, and follow-up were just as hard. Impact required both the assistive device *and* the educational system around it. I had to think about supply chains, instruction clarity, and sustainability—not just CAD files.

**Bionic Arms** took the same lesson further. I designed a fully articulated prosthetic arm for under $50—tendon-driven fingers, independent thumb, Arduino control, published STL files on Instructables. Commercial devices cost five figures; mine hit functional 5-DOF grasping at 1% of the price.

But cost, reliability, and open documentation weren't just "nice to have"—they were *product decisions*. Tendon stretch, servo current limits, joint alignment forced iterative mechanical redesign. I learned that hardware serving people requires both biomechanics depth and market-aware constraints: Who can afford this? How do they source parts? What breaks first?

---

## Products Live at the Intersection

**ValedictAI** put me in the middle of AI systems and a real user market. I built an AI-powered study platform—personalized tutoring, study-session tracking, document workflows—on a stack of Netlify, Supabase (Postgres/auth/storage), Google OAuth, Drive/Calendar/Classroom APIs, and AI APIs for assistance.

Multi-API products fail on auth and rate limits before features. Students need instant help—latency and trust beat feature count. I had to make technical trade-offs (which API calls to cache, how to handle token limits) while keeping the product *useful*. That's not a pure CS problem or a pure business problem—it's both at once.

**PARKLYO** reinforced this. I built an iOS app to pin anything in the real world—parking spots, meet-up points, bags—and find it later. Live on the App Store, I took it from concept to TestFlight to launch in three months, iterating across React Native and native SwiftUI/Core Location/MapKit/CloudKit.

Location products fail at edge cases simulators miss: parking garages, GPS dead zones, battery drain. Shipping forced local-first design, privacy clarity, and ruthless UX simplicity. I had to think about App Store positioning, user trust (why does this app need location?), and iteration from real feedback—not just Core Location documentation.

---

**BioCap**—my conductivity-based milk freshness sensor—closed the loop. It measures what's actually in the carton (bacteria raise ionic content), not a printed expiration guess. I won 1st place at CIJE Innovation Day and a 1st Place Invention award from the National Institute of Innovative Sciences. Survey data: 88% would use it daily; 91% were unsatisfied with expiration dates alone. The target: ~$2 billion in US household dairy waste.

I chose conductivity after evaluating pH strips and color sensors—biophysics insight led to an engineered product, then to market validation and impact. Hardware, firmware, and user research had to move together. The award wasn't for the sensor alone—it was for showing that the science, the build, and the go-to-market story made sense as a system.

---

## Why M&T

I've built AI platforms for financial institutions, assistive devices for refugee children, iOS apps on the App Store, and hardware that won national innovation awards. Every project taught me the same thing: **technical depth creates options, but business and organizational judgment decide what to build and how to ship it.**

M&T is the only program that treats this integration as the foundation, not a bonus. I don't want to learn Wharton strategy separately from SEAS systems—I need them in the same room, the same project, the same decision loop. I need to be in classes where we're debating *both* the architecture of a financial AI platform *and* the go-to-market for regulated industries. I need to work with people who see product, operations, and code as one problem.

I'm not hedging between two degrees. I'm committing to the only program that trains people to build systems that work—technically, operationally, and in the real world. That's M&T.