I build tools for specific people with specific problems, and I’m not done until I bring smiles to their faces.
Say hello: yuval@yuvallevy.dev or see the contact section below.
Levy - say it like “levee”.
Yuval - say it like “you’ve all”. Yes: it's what yuval been waiting for. 🥁
Aim to make work more efficient and more enjoyable. If a tool doesn’t give the user the faintest sense of delight, it isn’t finished – it’s just functional.
Most people don’t know they can have a better tool. Building it anyway, and quietly redefining what counts as good enough, is the actual job.
If an elegant solution doesn’t solve the problem and a hacky one does, ship the hack. Users can’t see how clever your code is, only how well it works.
Serve the under-served: the industries and communities that the tech world has left behind, and the people who never thought software could solve their problem.
A tool for drawing linguistic syntax trees the way you’d draw them on paper.
It spread almost entirely by word of mouth among professors, TAs, and students, and is now their go-to tool for this purpose.
Usability in tools for linguists often leaves a lot to be desired, and I wanted to raise the bar by building a tool that was a pleasure to use.
The highlight of my academic career was when a question on a final exam asked students to examine a tree drawn with NPBloom. I was one of the students taking that exam.
An online marketplace letting tree services sell their waste logs as material for wood products. I owned the UI and an SMS-based system for coordinating pickups: scheduling, rescheduling, delivery estimates, and more. SMS was where our non-technical users already lived, and getting them to download an app would have been a non-starter.
Forward Forestry was acquired by Cambium in 2024 and the whole team came along. I continued to work on the product and its integration into the Cambium ecosystem, this time implementing a design team’s vision instead of my own, down to the small details the lead designer was glad someone noticed.
A notification system is a high-stakes component of any product, and it’s critical to get it right. Accordingly, it was the most heavily tested part of the codebase.
I wrote a little language where each case reads like a screenplay: a timed exchange of messages a non-coder can follow like a script for a movie scene,
to pass to a product manager or designer and ask, “Does this look right?”
The very same screenplay would then compile down as valid test cases, since it was all valid code in the first place.
This made it easy to get feedback from non-technical stakeholders and iterate quickly, without needing to translate back and forth between English and code.
The content of each test case looked like this – this is heavily extended Kotlin code which compiles as-is:
The tests would run against a simulated notification system with a fake clock. Each replies line would trigger a response from one of the fake users, the Send lines would check that the system reacted correctly at the right time, and the later and At time lines would advance the clock and trigger any time-based events that were supposed to happen in the meantime.
We had about 150 such test cases covering a wide variety of corner cases. We would run them before each deployment, and any deviation from the script would cause the test to immediately fail and abort the deployment.
Many bugs did not make it to production thanks to this system, including ones that would have been tricky to catch, annoying for the users, and highly impractical to reproduce manually.
I find it extremely funny how quickly rounded corners go in and out of fashion.
Sometimes they stick around for years; other times they make a brief visit for a season and then disappear again, only to come back a few years later bigger and angrier than before.
So instead of me making a decision for this page, here you go: you drive. Drag the slider and watch the entire page change its mind about how round it wants to be.
Scroll around the page to see how the corners change.
I’m looking for a remote early-IC seat at a small-to-mid, mission-driven team, where “designer” and “engineer” aren’t kept in separate departments, and where someone can tell you clearly why the work matters in a way that you’ll be able to explain to a five-year-old.
My favorite problems to solve are those in messy, complex domains that haven’t been fully digitized yet, and where people are skeptical about software in the first place.
I get on best with people for whom anything can become a toy – those who tinker, who play, who never quite believed work and play were opposites. If your instinct is that the two shouldn’t mix, we’ll both be happier knowing it now.
Finally, I’ll tell you what I really think, not “brutally” but plainly and kindly, and I’d love exactly the same in return.