User experience
I work out what a screen needs to do, who is standing in front of it, and what they need to see first. The result is a design you can build from, with the decisions written down.
Hi, I’m Daniel. I do user experience work and build software for businesses.
I work out how a piece of software should behave for the people who use it, then I build it. I’ve been shipping software for about fourteen years, most of it the kind a business runs on. I’m in Cedar Park, Texas.
What I do.
Building software
I write the code and run it. Line-of-business systems, operator tools, back ends for fintech and insurance, and the surrounding pieces: data, background jobs, deploys. I like performance work, and I’m usually the one people call when a bug is hard.
Both together
Most projects need the design and the build to be the same person, so the design survives contact with the code. That is the work I take on most.
Who the work was for.
Four pieces of work from the last fourteen years, told from the side of the people who used them. I don’t name clients here; ask and I’ll walk you through any of them.
Fundraisers who had used a mainframe for twenty years.
They did everything from the keyboard and they were fast. Anything I built to replace it had to be faster, not just newer. I kept every screen keyboard-first, made search answer in under a second, and built the component library the whole platform ran on. One tool they had refused for two years went into daily use after I spent three months hiding its machinery behind sensible defaults. The receipt processors got eighty percent of their manual work back.
A support team that was sick of being woken up.
A healthcare payments platform arrived with its original engineers gone and nobody left to explain it. I learned it from the inside and found about a million dollars of members’ payments sitting unrecorded between the platform and the bank. Then I built the reports the operations team used every morning for the next two years, and trained the support analysts who took the night calls so the engineers could stop.
Three business units sharing one application.
An aviation maintenance tool where a bug for one unit was downtime for all three. I worked alongside the design team and the engineers to split it into three systems that ship on their own schedule, with deploys you can test before anyone sees them. The late-night pager went quiet.
Helpdesk agents with a caller on the line.
At a life and health insurer I own every screen a member, agent or employee touches, from the member portal to the systems behind it. For the helpdesk I built tools that put the right answer in front of a live agent while the person is still talking, and that notice when a call is going badly before the agent has to say so.
Code you can read.
Most of my own projects are around the Fossil version-control system. More at github.com/danmestas and fossil.craftdesign.group.
- zit
A version control system compatible with Fossil, written in Zig.
- zeitforge
A forge for Fossil repositories, running at zeitforge.app.
- dagnats
A DAG workflow engine on NATS for automated coding pipelines. Apache 2.0.
- go-sqlite3-opfs
SQLite persistence for browser WebAssembly through the Origin Private File System.
Firestorm DataWorks
Firestorm DataWorks makes flight preparation simpler by separating signal from noise. It takes FAA and NOAA data and classifies and ranks the NOTAMs and weather, so pilots and dispatchers see what matters for their flight.
It is in development and not yet available to the public.
Software that holds up after it ships.
Match the constraints, not the trends.
Cloud, self-hosted, or local-first depends on the team, the risk, and the budget, not on what is popular this year.
Build the surrounding machinery.
A feature is not done until it has runbooks, observability, and a way to roll it back.
Get in touch
If you have software work and want to talk it through, email me or use the form.