Small C# desktop tools that fix big FiveM problems
July 4, 2026 · by Wax
A lot of my most useful software isn’t a product anyone will ever see. It’s a folder of small desktop utilities I wrote because the alternative was doing something tedious by hand a thousand times. None of them is clever. All of them saved me days.
The pattern: a repetitive problem the ecosystem ignores
FiveM is full of these. Textures that need downsampling in bulk. Level-of-detail models that get duplicated across packs. Clothing that needs converting between formats. A music library that needs organizing into the structure a resource expects. Each one is a real chore, each one is mechanical, and none of the “official” tools touch it. That combination — repetitive, mechanical, unserved — is the exact signature of a problem you should automate.
Why C# for this
For Windows desktop utilities that chew through files, C# is a sweet spot: it’s fast, it handles binary formats without drama, and I can hand a non-technical teammate a double-clickable executable instead of a script and a lecture. I reach for Python when it’s glue or data work — the same “pick the tool for the job” instinct I write about in automating repetitive tasks — but for a click-to-run file cruncher, C# wins.
The economics of a 200-line tool
Here’s the math that justifies it. If a task takes twenty minutes by hand and I do it weekly, that’s seventeen hours a year. A focused tool that takes an afternoon to write pays for itself in a month and then keeps paying, forever, with zero effort and zero human error. The one I built to shrink oversized streaming assets is the clearest example — it turned an impossible manual audit into a repeatable pass.
When NOT to build one
The trap is building tools for problems you have once. If it’s a one-off, do it by hand and move on — the tool is the expensive option for a task you’ll never repeat. Build only when the task is going to keep coming back. Repetition is the entire justification; without it you’re just procrastinating with extra steps.
Most of these will never ship publicly, but the mindset behind them is exactly what I bring to custom software work: find the mechanical pain, measure the payback, and build the smallest thing that kills it.