The Helpdesk Nobody Built, So I Did

Published: 1 January 2026

Every helpdesk I’ve ever used felt like it was designed by someone who’d never had to use one.

When I started at Nossal High School as a Specialist Technician, that feeling became my daily reality. We were running ManageEngine ServiceDesk Plus. On paper, enterprise-grade. In practice, a slow, bloated mess that seemed to exist purely to generate metrics nobody ever had time to look at. Every feature felt bolted on as an afterthought for some other customer’s edge case, and we were left navigating a labyrinth of options designed for an organisation ten times our size.

In a dynamic environment like a school, you get repetitive issues constantly: devices need reimaging, students can’t connect to WiFi, screens are cracked. These aren’t complex problems, but they’re high-volume. You need to triage fast, track devices efficiently, close tickets quickly, and get students back to learning. ManageEngine made me click through five screens and fill out forms designed for enterprise change management workflows.

There had to be something better.

The Search for Something Better

Spiceworks became our temporary lifeboat after we decided to ditch ManageEngine. We were only looking for something basic and self-hostable to keep us moving. The open source version was no longer receiving updates, and Tony, an absolute legend I worked with, was already experienced with it.

From the options we could find, Zammad seemed like the most reasonable approach. It was open source with a good community, and I figured I should be able to add the features and support I needed to make it work. The interface was thoughtfully designed and it didn’t cost a fortune, so we migrated everything over.

But then small frustrations started appearing. Custom attributes on print previews didn’t work the way we needed. When I found an existing GitHub issue and followed up on it, one of the lead developers responded with:

I’ll have to quote myself: When we introduced the print layout we decided against showing ticket meta information as far as I can remember.

This repository is not the right place for technical questions, please consult our Community instead.

Eventually I solved it myself and posted the fix, but got no reply. I kept trying to make other improvements, but the realisation that I’d be spending more time hacking around the software than actually using it forced me to reconsider.

The Disconnection

Around this time, I was reading Katie Hafner’s Where Wizards Stay Up Late, about the origins of the internet. There’s a moment where Bob Taylor, sitting in his Pentagon office in 1966, stares at three disconnected terminals and asks: why can’t these things just talk to each other? His answer became ARPANET.

That question stuck with me. Because my desk told the same story: three browser tabs open. Our helpdesk for logging tickets, Microsoft Intune for device information, and our hardware vendor’s portal for warranty claims. I was copying serial numbers between them, cross-referencing student names, manually bridging systems that had no idea the others existed.

Once you see the disconnection, you can’t unsee it.

Beginning with the Frontend

In February 2025, I started actively working on Nosdesk.

All the times I’d used a helpdesk and thought “why can’t it just do that?” I channelled into the design. And I was having so much fun working on it.

Voice notes, so you can record a ticket description from your phone instead of typing it out while five people wait in line behind you. Sensible keyboard shortcuts. Efficient bulk operations. Search that returns relevant content from the deepest parts of the system in under three seconds.

Integrated documentation, so the valuable information buried in tickets can be easily referenced and turned into a lasting knowledge base instead of being tossed into a void when you close it.

Something modern and responsive. Something that felt like the tools I used outside of work, not enterprise software that was born before me.

That was the vision. Now I had to build it.

The Backend

As if the tech debt wasn’t enough, I made another reckless decision: Rust over Node.js.

I was already getting accustomed to Rust by this point. But the compiler doesn’t care how comfortable you feel.

I’d spent years watching developer convenience get prioritised over user experience. Abstractions layered on abstractions. Slow runtimes justified by faster development cycles. Bloat accepted as the cost of shipping quickly.

If I have to fight the compiler so that technicians don’t have to fight the software, that’s a trade I’ll make every time.

From there it was all foundation work. Researching libraries, evaluating crates, building something that wouldn’t buckle under load. Postgres and Diesel for the database. Actix for the web server. Fast by design, not by accident.

There was one big design consideration I couldn’t ignore: multiple technicians editing the same ticket at the same time. Merge conflicts. The classic solution is to lock the record or force a refresh, but I wanted something better. I wanted a live environment where you could see changes in real time, without stepping on each other’s work.

CRDTs over WebSockets ended up being the answer. Conflict-free Replicated Data Types, the same technology that powers collaborative editors like Figma and Notion. I’m standing on the shoulders of giants here: Yjs for the CRDT implementation, yrs for the Rust port, and ProseMirror for a rich text editor that actually works. Now hundreds of techs can type in the same ticket notes simultaneously if they really insisted, and it just works. For everything else, comments, general ticket data, I used Server-Sent Events to keep things in sync without the overhead.

I’d sometimes use Nosdesk to track jobs as I went. But I was iterating too fast to rely on it. Rethinking architecture, refactoring constantly, breaking things along the way. My workflow was being held together by a pile of sticky notes.

Moving Forward

Then life happened. Midway through 2025, I was offered a position as an infrastructure engineer. I took it. Development slowed. My evenings shifted to learning the demands of a new role, and Nosdesk sat half-built in a repository on my MacBook.

Quitting was never on the agenda. But I had to balance everything, and for a while the balance tipped away from the helpdesk. Eventually I realised that if I didn’t just keep going with it, it was never going to exist.

The feeling that started this never went away. The conviction that something better should exist. Only now it wasn’t for me. It was for the school. For the team I was leaving behind. For every small IT operation still copying serial numbers between three browser tabs.

I had to keep building.

Making It Happen

It’s now 2026. Nosdesk still isn’t finished, but it’s nearing a production-ready state.

Real-time collaborative editing on tickets. Voice notes with automatic transcription. A knowledge base that turns your ticket resolutions into searchable documentation instead of letting them disappear. Asset management that actually links devices to tickets and users. Microsoft Entra authentication built in from the start. Sub-100ms response times, because I chose the hard path with Rust and it paid off.

I’m moving ahead full force now, trying to get this into the hands of the people who need it. Small IT teams. Schools. Lean operations that have been underserved by enterprise bloat and abandoned open source projects.

The systems are finally going to talk to each other. And the person sitting in front of them is finally going to feel like the software is on their side.

A helpdesk that moves as fast as you. That’s Nosdesk.