A private userscript for the boring parts of data annotation
January and February 2026 I was a data annotator. The work was repetitive, the tracker was annoying, so I built a userscript to handle the menial stuff for me.

For five weeks at the start of 2026 I was a data annotator at Innodata. The work was straightforward - review training data, check labels for prompt match and accuracy, follow guidelines, file the result. It's important work. It's also, by design, repetitive. Repetition is what makes the dataset consistent. It's also what makes annotation jobs feel like a special kind of grind.
What I didn't expect was how much of the day was not annotation. There was a job tracker that wanted me to log time-in and time-out separately from the platform clock. There were menial steps before each task - selecting the right project, opening the right ticket, switching modes. None of those steps were hard. They were all a few clicks. They added up to a real fraction of the day.
Within the first week I started thinking about a script.
What I built
The userscript ran in my browser as a Tampermonkey-style addon, kept private because the workflow it touched was internal. It didn't do anything that affected annotation quality. It handled the surrounding bookkeeping - the part that was the same every shift no matter which project I was on.
It detected when I logged into the system, automatically filled in the time-in field on the tracker. It watched for the platform's logout signal and posted the time-out. It pre-selected the menial defaults that were the same for every shift. It saved me from clicking through the same series of dropdowns hundreds of times across the assignment.
I want to be clear about what it didn't do. It never auto-submitted annotations. It never bypassed any quality check. It never made decisions on my behalf. It just removed the clerical work that surrounded the actual annotation tasks. Every annotation I submitted was reviewed and tagged by me.
Why I built it
A useful filter for "should I automate this" is: would I be embarrassed to tell a teammate I do this manually? When the answer is yes - when the task is so mechanical that explaining it out loud feels silly - that's the signal. Time-in/time-out is exactly that kind of task. Selecting the same defaults at the start of every shift is exactly that kind of task. None of it required judgment.
The other reason was self-respect. The annotation work itself required real attention. Image Object Picker, Furniture Removal, Text-to-Image H2H, and other project types each had their own guidelines, edge cases, and quality bars. Spending mental energy on the wrapping-paper bookkeeping meant I had less attention for the actual review. Removing the wrapping paper meant I could give the annotation work the focus it deserved.
What I learned
Two things stuck with me from this:
Boring work is a signal, not a complaint. Every menial step in a workflow is a place where automation could live. The trick is to look for those steps without contempt. They aren't bad - they're just not the part that needs your attention. Building a small tool to absorb them is one of the highest-leverage things you can do during repetitive work.
Constraints make tools sharp. The userscript stayed small because I wrote it for myself, on my time, against a system I understood from the inside. There was no roadmap pressure, no abstraction to make it generic for other annotators, no marketing surface. Just a single user with a real problem, building the smallest thing that solved it. The best tools I've built have all started that way.
When the assignment ended, I retired the userscript. It had done its job. The lesson it taught me about looking for the menial layer carried over into every project I've worked on since.