Mechanical Engineering student at Arkansas State University. Built TechShortsApp (credibility-based ranking system) and TechXEng (systems thinking platform).
I'm an undergraduate Mechanical Engineering student building real things in parallel — software products, engineering projects, and long-form technical writing. My work lives at the intersection of how systems are designed and how they fail under uncertainty.
Right now I'm focused on TechShortsApp, learning SolidWorks and hydrogen turbine systems, and documenting technical ideas publicly through TechXEng. Everything connects back to one question: how do you make confident decisions with incomplete information?
My default mode is to reduce uncertainty. I ask what assumptions are hidden, what evidence is actually available, what constraints matter most, and how confidence should update as new information appears.
I treat both engineering and software as the same underlying discipline: you're always working with inputs, outputs, feedback loops, and limits. Understanding the structure of a system matters more than memorizing its parts.
My projects start with a technical question and become a product, framework, or documented learning system.
A credibility-first video platform exploring how information systems can rank content using behavioral evidence rather than popularity alone. The core insight: credibility is not a binary label — it's a confidence score that updates as evidence accumulates. I built a probabilistic ranking approach using watch ratio, replay behavior, bookmarks, and early exits. Version 1 was killed when it relied too heavily on simple engagement metrics. Version 2 rebuilt around uncertainty, domain-aware freshness, and explicit acknowledgment of what the system cannot claim.
A public learning lab where engineering, software, and systems thinking are explained through one consistent framework. Rather than isolated tutorials, TechXEng connects ideas across domains — showing how the same underlying structure (inputs, outputs, constraints, uncertainty) applies whether you're analyzing a turbine or debugging an API. It's a living record of understanding built through building, not memorizing.
A deep engineering effort focused on understanding hydrogen turbine systems from first principles — energy flow, component roles, combustor zones, and system-level constraints. I use the same framework I apply to software: trace what enters, what exits, how the parts interact, what limits performance, and where the unknowns live. This connects directly to my long-term goal of building physical systems that operate reliably in uncertain environments.
Whether I'm studying a turbine, building a ranking algorithm, or explaining a concept publicly — I try to understand the same structural layers first. This isn't a methodology. It's just the honest shape of how any system works.
I arrived at this framework after noticing I kept asking the same questions across different domains — engineering courses, software architecture, and credibility research. The questions weren't discipline-specific. They were structural.
What enters a system? What comes out? How do the parts interact? What sets the ceiling? And critically: what don't we know yet, and how should that change our confidence?
What enters the system — energy, data, assumptions, material, user behavior, or information.
What the system produces — motion, rankings, learning, work, heat, or failure modes.
How the parts affect one another internally. Where feedback loops form. What amplifies or damps.
What limits the system — physics, time, incentives, available resources, or design decisions.
What's still unknown. How confident should we be? How does that confidence update with new evidence?
The early version relied on simple engagement metrics. Easier to build — but the wrong signal for actual technical reliability. Not aligned with what the platform was supposed to do.
Rebuilt from the ground up around uncertainty, evidence quality, domain specificity, and time-sensitive knowledge decay. Limitations are now explicit rather than hidden.
Arkansas State University
Self-directed · Real project building
Thermodynamics, fluid systems, mechanical design, engineering analysis, and SolidWorks. Learning how physical systems convert, transfer, and lose energy.
React, Next.js, Node.js, Express, MongoDB. Full-stack product architecture from storage and APIs to frontend and deployment.
Technical writing, structured documentation, educational scripting, and public explanation of engineering and systems ideas.
Build full-stack applications using Next.js, Node.js, MongoDB.
Break down complex systems into inputs, outputs, constraints.
Connect mechanical systems with software-based solutions.
I'm actively seeking robotics, mechatronics, engineering, and systems-focused software internship opportunities where I can grow through real technical work.
Open to engineering internships, research collaborations, and technical conversations. Especially interested in opportunities involving robotics, mechatronics, and systems that need to operate reliably in the real world.