One File, One Saber
How a Colorado builder got tired of juggling folders and quietly rebuilt the ProffieOS workflow from scratch
By Claude (Anthropic)
This article was written by Claude, Anthropic’s AI assistant. It is based on a recorded interview Claude conducted with Ryan of Jedi Master Tech on June 4, 2026. Claude prepared the questions, ran the interview, and wrote the piece. Ryan reviewed it for factual accuracy and provided editorial direction. Direct quotations are drawn from the interview transcript; nothing here was invented or embellished beyond ordinary cleanup of spoken filler.
A note for the skeptics: “AI-written” usually means nobody checked. This is the opposite. The subject sat for a real interview, answered in his own words, and verified every claim and quote before publication. The machine did the drafting; a named human did the vouching. That division of labor — AI for the prose, a person accountable for the truth — is the part worth standing behind.
If you’ve built more than a couple of Proffie sabers, you already know the folder.
It lives somewhere on your drive — Lightsaber, Sabers, or maybe Proffie stuff — and inside it is a sprawl of sub-folders, each one named for a build. Sabine Wren. Ezra Bridger. Graflex. Darth Vader. And then the ones whose names only mean something to you: primary, secondary, one-button baselit. Open any of them and you’ll find a full copy of ProffieOS sitting there, dutifully duplicated, wrapped around a single config file that describes how that one saber is wired and what it’s supposed to do.
It works. Thousands of builders run some version of this system. But Ryan — the maker behind Jedi Master Tech, working out of Aurora, Colorado — looked at his own version of that folder one day and decided it was quietly driving him up the wall.
The day-to-day was a juggling act. “I’d want to work on a particular saber because I wanted to add some sound fonts — change the order, add a new style, whatever it was,” he says. “And it would mean finding that particular one and opening it in multiple places. The config in Notepad++, the .ino in Arduino, and then just making sure you’ve got the right ones open so you can edit it and then flash it.”
The breaking point wasn’t the tedium, though. It was the math. Every duplicated folder carried its own complete copy of ProffieOS. And every time a new version of the firmware dropped, Ryan faced the same demoralizing question: was it worth going back and rebuilding that entire structure for every saber he maintained?
The answer he arrived at was different from “do it more carefully.” It was: build something better.
A browser, a wall, and a pivot
JMT Studio didn’t start as a desktop app. It started, like a lot of good tools, as a small itch.
Ryan already kept a handful of utilities on a quiet little Vercel site — simple, useful things, like a converter that turns an ordinary RGB color into the 16-bit value ProffieOS templates actually want, so he could drop colors into a config without doing the conversion in his head. The natural next thought was: why not build the editor there too? A Monaco-based editor — the same engine that powers VS Code — that would give him the parts of Notepad++ he liked, but Proffie-specific, right in the browser.
He got the editor working. Then he hit the wall every web developer eventually hits when they try to talk to real hardware: the browser doesn’t want to let a web page reach down and touch a physical board. The permission story for serial communication from inside a browser was, in his words, “a nightmare.”
So he pivoted. He went looking for the best way to build a genuine cross-platform desktop application, landed on Electron, and — as he puts it — “the rest is history.”
That pivot mattered more than it sounds. It’s the difference between a clever toy and a tool you can actually flash a board with.
The idea that made it click
Here’s the architectural insight that turns JMT Studio from “a nice config editor” into something genuinely new.
Ryan didn’t want to keep duplicating ProffieOS. He didn’t want a full copy of the firmware buried inside every project folder. So he flipped the model: instead of welding a copy of ProffieOS to every saber, manage the firmware centrally and let the config travel.
JMT Studio holds your ProffieOS versions in one place — latest stable, an older release, a beta you want to kick the tires on. You can import a copy you already have, or download one fresh straight from the official ProffieOS GitHub without leaving the app. A config isn’t married to any one of them. Open it, pick a version, compile, flash. Want to see how a known-good build behaves on new firmware without disturbing your working setup? Point it at the beta.
So it isn’t quite “one ProffieOS.” It’s one per version, shared by everything you build — and a config that’s free to move across all of them.
The consequence is the line that has quietly become the whole philosophy of the product: one file is one saber. No wrapper folder. No duplicated firmware. No copying things into place and praying you copied the right one. Your entire library becomes a flat folder of small, self-contained .h files, each one carrying its own description and board type baked right in — and the firmware versions sit off to the side, shared by all of them.
There’s a deeper motivation underneath the cleverness, too. Ryan is candid that part of why he wanted to own the workflow end-to-end wasn’t ideological — it was about support. “I appreciate open source,” he says, “but I was looking for something I could have more control over, so I could support it better if I’m going to give it to other people. Not to make money — really just to make sure it was going to work.” Managing the firmware versions inside the app, rather than leaving every user to wrangle their own toolchain, is that principle in practice.
Not a wizard. Not a black box.
There’s a well-trodden path in this hobby for making Proffie “easier”: build a graphical generator. Checkboxes, dropdowns, pick your options, click a button, and out comes a config. Some of those tools are excellent, and Ryan is quick to say so.
But that’s pointedly not what JMT Studio is.
“I’m still letting you see the raw configuration file,” he says. The app doesn’t hide the config behind a friendly form and hand you something you don’t understand. It shows you the real thing — and then layers helpers on top of it for the parts that are genuinely painful in plain text.
The clearest example is the style library. Early on, Ryan realized he didn’t want his blade styles living directly inside his configs — it made them long, messy, and miserable to share between builds. So he pulled them out into a separate header full of helpers and referenced them by name. It’s a pattern plenty of experienced builders use. But because JMT Studio understands that pattern, it can do things plain text can’t: a visual editor for your styles, and a visual editor for your presets where you can reorder them and rearrange the things that are genuinely fiddly to manage as raw code. Your config gets simpler — it’s just references now — and your styles become a library you draw from across every build.
Ryan is careful about the word “simpler.” Configs, he points out, aren’t code exactly, but they’re written like code. “They’re really just telling the real code what to do, if you use the right syntax. I wanted to simplify some of that — but I didn’t want to take over for it.”
That same instinct shows up in the firmware itself. Ryan has built a handful of features on top of Fett263’s prop — his favorite — as a wrapper, not a substitute: charge detect, chassis detect, enhanced blade detect, a preset favorites system. JMT Studio is what makes it clean. When a user opts in, the app pulls the necessary files from Ryan’s own GitHub and they simply become available in the config. Nothing’s forced on anyone, and the underlying prop stays exactly what it was.
That restraint runs through the whole app. The other principle he keeps coming back to is transparency. Board detection is a good case study. Anyone who’s flashed a Proffieboard knows the dread of the board that won’t show up, the dance into bootloader mode, the hunt for which COM port is which. JMT Studio makes board detection automatic — you don’t have to know what port anything is on — but, crucially, it never does anything magically. “There’s always transparency in telling people what they’re doing,” he says. You still do the bootloader dance when a board needs it; the app just stops making you guess.
A few other touches round it out. If a config compiled cleanly once, why compile it again? A validated build can be reused, so reflashing doesn’t mean waiting through another full compile. There’s diffing built in — both against your own unsaved changes and between two separate configs — because, as Ryan notes, a “new” saber often isn’t a clean-sheet build at all. It’s tweaks on one you already did, ported across.
Thirteen hundred ways to break it
Here is the part that should make experienced builders sit up.
Before Ryan has shown this to a single other Proffie user, he has run it through more than thirteen hundred test cases — a QA process he designed for himself, then ground through methodically: find a bug, fix it, regression test, repeat.
And he didn’t just test it on his own happy-path machine. He built virtual machines so he could see the tool the way a stranger would. A clean Windows install. A clean Mac. A clean Linux box. What happens for a first-time user who’s never touched any of this? What happens for the veteran who already has Arduino and the Proffie toolchain cluttering up their system? Both scenarios, tested in isolation, deliberately.
(That Linux testing earned its keep, incidentally. Somewhere in there lurked a permissions bug — a missing group membership that silently blocked serial access, the kind of thing that would have left a first-time Linux user staring at a board that simply refused to appear. Caught, diagnosed, handled.)
The cross-platform discipline shows up in the small stuff, too: the Mac build is properly signed and notarized, with a real app icon, rather than the unsigned-binary-that-macOS-screams-about experience that so often greets hobbyist tools.
“I wanted something I could be proud of,” Ryan says. “Something I could stand behind.”
The builder behind the build
It’s worth pausing on who’s doing this, because it explains a lot.
Ryan isn’t a software company. By day he works in IT and cybersecurity, and he’s frank that the way he thinks about systems — break the workflow into modules, find where it fails, link it back together — is something he carried straight over from his professional life into this. By night and weekend he’s a serious maker: CNC, 3D printing, woodworking, lathe work, electronics down to surface-mount soldering. He’s built a lot of sabers. JMT Studio wasn’t conceived in the abstract; it was the answer to a problem he was living with personally, every time he sat down to tweak a style preset.
That’s also why he’s kept it close. He hasn’t handed it to other Proffie people yet — on purpose. “I wanted to build confidence in the tool before I put it out there,” he says. “If I start building by committee, it’ll slow the work down. I just wanted something completely functional that met all of my needs. And if it meets mine, I believe it’ll meet others’.”
It’s an unfashionable way to build a community tool in an era of public betas and feedback forms — but arguably why it’s as solid as it is.
The launch, and the honest caveat
As of this writing, JMT Studio has reached version 1.7.0 — and for the first time, Ryan is calling it done and stable. An earlier 1.6.5 went up quietly on his site without fanfare. 1.7.0 is the one he’s ready to actually talk about.
The plan is two-pronged. First, The Crucible — the home of the diehard Proffie crowd — where he expects (and welcomes) real feedback and the occasional bug report, and where earning genuine respect matters. Then YouTube, aimed at a different audience entirely: people who are curious about building, maybe intimidated by Proffie, maybe coming from something simpler like XenoPixel, who’ve never believed Proffie was for them. Tutorials that teach Proffie through the tool come later.
That second audience is the quietly ambitious part. Ryan thinks JMT Studio can make ProffieOS not just manageable but genuinely approachable — in some respects easier than the budget boards people start on. (He’s careful to note that authoring styles from scratch is its own beast, and one he deliberately didn’t try to swallow.) Down the road he muses about a community style library where builders could share and tweak styles — always with attribution intact, he stresses, to the Fett263s of the world whose work underpins so much of this hobby.
Honesty requires one caveat, and Ryan would be the first to insist on it: the real test hasn’t happened yet. Thirteen hundred self-authored test cases is a remarkable amount of rigor for a solo project, and the VM matrix is smarter than most commercial software gets. But no amount of self-testing fully substitutes for a few hundred strangers using a tool in ways its maker never imagined. The proof of JMT Studio will come when The Crucible gets its hands on it.
Everything up to that point, though, suggests the proof is going to land well.
The pitch, in the end, is disarmingly modest — and a lot harder to argue with than your way is wrong:
This solved my problem. I really think it could be good for you. And I’ve added some things along the way I think you’re going to enjoy.
For a hobby built on people quietly making the thing they wished existed, it’s hard to imagine a more fitting origin story.
JMT Studio is a desktop application for editing, compiling, and flashing ProffieOS configurations, built by Ryan of Jedi Master Tech. Version 1.7.0 is slated for public release on The Crucible. More details and downloads at jedimastertech.com.