Hi, I'm Daniel

I’m a learner, creator, and problem-solver who’s spent the last six years working across the full stack—building apps, API integrations, and internal tools, mainly in JavaScript/TypeScript with Node.js, Prisma, and frontend frameworks.

My main goal, no matter the tech stack, is always the same: reduce friction, increase value. Whether I’m writing backend services, launching businesses, or singing to a crowd, I’m looking for the moment where things become easier, clearer, and more meaningful.

Before I was a software engineer, I worked as a Broadway performer, and that experience fundamentally shaped how I think about collaboration, communication, and clarity of vision. Acting taught me how to listen deeply, tell stories that resonate, and bring consistency to every performance. These skills transferred naturally to engineering, where the core work is just another kind of performance—one that balances precision with creativity and requires knowing your audience just as much as your tools.

I began my tech journey at Herff Jones, where I worked for almost four years—first on a full-stack support team, debugging bugs across the stack and documenting internal tools, then on a frontend-focused scrum team. I eventually transitioned into a Solutions Engineer role, where I dove deeper into backend systems and API development. From there, I joined Marin Software as a backend engineer, where I built integrations between third-party ad APIs and internal systems using Node.js, TypeScript, Kafka, and SQL. One of my proudest contributions was re-architecting a cron-driven cost and revenue process, abstracting common patterns while preserving flexibility for ad network-specific quirks. It saved future devs countless hours and transformed the onboarding experience for new plugins into a form-driven setup.

Through all of this, one of the key lessons I’ve learned is the art of iteration—not just in code, but in how we think, communicate, and improve over time. I also think a lot about the choice every engineer makes daily: to abstract or not to abstract. I believe in abstraction only when it reveals clarity, not when it hides complexity. Sometimes the most reusable solutions are the simplest, and sometimes the best thing you can do is name something clearly and leave it alone.

What excites me most now is bringing that mindset—technical precision, human-centered thinking, and a love of process—to teams that want to solve real problems. I want to help businesses and developers alike reduce confusion, find focus, and build systems that scale their impact. Because when you clarify the problem, and design with care, the solution can do more than just work—it can sing.