Jagger Brulato
Full-stack engineer working across product, platform, and language tooling.
I like working on software that crosses boundaries: product work, backend systems, internal tooling, and the weird projects that force you to understand how things actually work.
- Most of my work has been some mix of product delivery, platform thinking, and developer-facing tooling.
- I’m happiest when I get to move between the UI, the backend, and the operational side of the system.
- JaggerScript is the clearest side-project example of that: language design, runtime work, and a browser experience around it.

The work I’m most drawn to usually creates leverage somewhere.
That can mean product features, platform work, developer tooling, or just making a system easier for the next person to work in.
Own the whole path
I like being able to follow a problem from the interface all the way down to the backend and operational details.
Bring systems thinking into product work
A lot of what I’ve learned from systems and platform work shows up in how I build product software too.
Build things other engineers use
Some of the most satisfying work for me is tooling, visibility, onboarding, and internal abstractions.
This is the fastest way to get a feel for the kinds of work I’ve done.
It spans product engineering, platform work, and leading teams while still staying close to the code.
Red Ventures
Platform Engineer
Worked on internal platform capabilities and tooling for engineering teams.
- Worked on internal application platform work used by engineering teams.
- Built better visibility into cost, availability, and process health.
- Spent a lot of time in the space between platform reliability and day-to-day developer experience.
Software Engineer
Worked as a software engineer in a large production environment.
- Got experience shipping in an environment with real scale and mature engineering processes.
- Spent time around the kinds of reliability and quality expectations that come with that.
- Worked in a place where collaboration and clean execution mattered.
Cornell Design & Tech Initiative
Developer Lead and Technical Project Manager
Led student developers while still staying hands-on with implementation and technical direction.
- Worked across web, Android, iOS, Windows, and backend services.
- Handled technical direction for the Cue subteam.
- Did a lot of onboarding, unblocking, and feature work at the same time.
Lowe’s
Software Engineering Intern
Worked on Lowe’s Central Price Master across frontend, backend services, and DevOps tooling.
- Built frontend features in Angular and TypeScript.
- Worked on backend APIs in Spring Boot and Java.
- Used the surrounding delivery stack: GCP, Docker, Jenkins, Jira, and Bitbucket.
Velocitor
Software Engineer Intern
Built cross-platform mobile software in C# and Xamarin for client projects.
- Worked on client applications for things like inventory, driver tracking, and scheduling.
- Built in a cross-platform mobile stack before that workflow became more common.
- Got early experience shipping software tied to real operational use cases.
These projects fill in the rest of the picture.
They’re the ones that say the most about what I like building when nobody is assigning it to me.

jaggerscript
JaggerScript
A small object-oriented language with its own parser, interpreter, and browser playground.
This is probably the most complete example of the kind of side project I like building.

domes
Domes
An online multiplayer board game inspired by Santorini.
I built it because I like stateful interactive systems, especially when the product side and the technical side are tightly coupled.

genetic-ts
Genetic Algorithms in TypeScript
A rebuilt interactive simulation where a genetic algorithm learns the launch velocity needed to hit a target.
I wanted this to feel like a real tool: tweak the physics, reroll the target, and watch the population adapt in real time.

materialize
materialize()
A Firestore utility for resolving reference-heavy data into something easier to consume.
It’s a small example, but it shows the kind of backend utility work I enjoy writing.
The stack matters less to me than how the pieces connect.
I care a lot about good boundaries, good defaults, and making software easier to work in over time.
Working with a team
I tend to end up in roles where I’m writing code, helping make decisions, and unblocking other people at the same time.
Systems and platform work
A lot of the backend work I enjoy ends up around reliability, observability, and internal architecture.
Range
I like not being boxed into one layer of the stack.
If this looks like the kind of background you need, reach out.
I’m especially interested in work where product thinking and technical ownership both matter.