Projects are where I let myself ask questions without being handed answers.
They're where I slow down and decide what actually matters — what should be automated, what should be visible, and what should be left simple. Unlike production systems, projects give me room to experiment, to make mistakes, and to understand why certain choices work better than others.
Featured Work
One of the projects I've spent the most time with is Truest Ride.
It started as a response to a very ordinary problem — getting from one place to another without uncertainty. I wanted to build something that felt calm and trustworthy, even while things were happening in real time. I approached it as a full system, not just an interface.
I designed the frontend with [React], focusing on navigation that didn't ask too much from the user. State management and routing were treated as first-class concerns, because confusion often starts there. Authentication was kept lightweight, avoiding unnecessary friction while still respecting identity.
On the backend, I built services using [Python x Flask], backed by [MongoDB], shaping APIs that stayed predictable as the system grew. Real-time communication mattered, so I integrated live updates and in-app messaging using [Socket.IO], making sure users could see what was happening without refreshing or guessing.
What this project taught me wasn't a framework or a pattern — it was how different parts of a system lean on each other. How frontend decisions affect backend load. How real-time features change how people behave. And how trust is built quietly, through consistency.
Most of my projects follow this same rhythm. I like owning the entire flow — from data to behavior to experience. I care less about how many features exist, and more about whether each one earns its place.
This page isn't a gallery of everything I've built.
It's a snapshot of how I approach building when I'm free to explore.
If something here feels deliberate, it probably is.
If something feels simple, it took time to get there.