A builder’s narrative
I gravitated to frontend early because it’s the surface where intent meets reality: pixels, latency, copy, and flow decide whether someone keeps going or quietly leaves. That’s a humbling place to work—you can’t hide behind abstractions when the user is staring at the result. Over the years that instinct turned into a repeatable lens: what job is this screen doing, what constraint is non-negotiable, and what is the smallest change we can ship that measurably improves trust, clarity, or speed? I still write UI, but the question behind the UI is what scales across teams and products.
At Luma Health I spent meaningful time inside the Communication Hub—a heavy, high-traffic workflow where performance and clarity aren’t polish; they’re part of care coordination. The product had picked up layers of UX friction and legacy code paths that made every change feel risky, which is how teams slow down without noticing. I helped refactor that surface so the experience felt lighter for real users, and we used feedback channels (including user reports) to validate that we were fixing what people actually felt—not only what was easy to measure on a dashboard. In parallel I treated security as part of the user experience: user-generated rich text is a classic foot-gun for XSS if you only sanitize “somewhere.” I helped eliminate critical exposure by sanitizing content before API processing and again at render boundaries, and I contributed to shared component APIs and design-system decisions so other squads didn’t have to rediscover the same sharp edges.
Some of my highest-leverage work sits where UX, backend behavior, and operations meet—where a brittle integration becomes tickets, churn, or a late-night page. One example: an SFTP broadcast pipeline where “it works on my machine” wasn’t enough for customers on sensitive data flows. I redesigned it so teams configured external→internal field mappings in the UI with validation instead of guessing and flooding support. Misconfiguration tickets dropped sharply, and we protected a relationship that couldn’t afford sloppy handoffs. At Sisnet I worked on a curated marketplace where content velocity mattered as much as code quality. I built an AdminJS CMS on Node.js so marketing and ops could ship copy, imagery, and styling without engineering for every tweak—weekly fire drills fell to “almost never,” and the team could focus on subscriptions, Stripe and Klaviyo, and product depth over routine publishing.
Outside of my full-time roles I co-founded Membrus: a platform for churches to run membership, communication, and operations in one coherent system instead of a patchwork of spreadsheets, group chats, and ad hoc tools. The work wasn’t “add another CRUD app.” It was understanding how pastors and staff actually move through a week—who needs access to what, what breaks when data is inconsistent, and how to ship admin workflows that non-technical people can own. I owned product and delivery across surfaces: public presence, member-facing experiences, and internal tools, iterating with church leaders who were generous with honest feedback. That’s the kind of product I want to keep building: grounded in real constraints, shipped to real users, improved in public—not slideware.
At Shifting I worked in a small team shipping a ticketing marketplace under real scope pressure—speed mattered, but so did not burning people out. I often acted as the person who had to choose: what do we cut, what do we harden, and what do we refuse to compromise on? My bias was toward shipping well, not shipping chaotically: daily unblocking, consistent code review so feedback was predictable, and small DX improvements that made the next week easier than the last. I also built internal CMS-style tooling so non-technical teammates could iterate content without engineering becoming a bottleneck. The result wasn’t just “we launched”—it was a functional marketplace delivered at a sustainable pace, with a customer who felt genuinely well served. That outcome matters to me as much as any technical detail.
This site is intentionally more than a static resume. It’s i18n-first, shares UI across the monorepo, and uses motion with restraint so reading stays pleasant on long pages like this one. Lucas AI is part of the same thesis: an assistant that answers in first person, but only from structured context published here—projects, experience, and how I think about trade-offs—so exploration feels grounded instead of generic. If you’re reading this far, you’re seeing the craft argument in miniature: narrative, systems, and a product surface that invites depth.