DEV Community: Jay Grider

How I Turned the Bad Into the Good - or how Neurotypicals Drove me to Build a Focus App for my ADHD Kin

Jay Grider — Sun, 12 Apr 2026 02:30:30 +0000

There's a specific kind of frustration that comes from opening a productivity app and immediately feeling less productive.

You know the ones. The confetti animation when you complete a task. The streak counter that makes you feel guilty for taking a weekend. The dashboard covered in badges, charts, color-coded urgency labels, and a leaderboard nobody asked for. They're designed to be motivating. They're designed by people who find that stuff motivating.

I am not those people. And if you clicked on this post, there's a decent chance you aren't either.

The Problem With "Productivity" Apps

I've spent years watching the productivity app space evolve, and the trajectory is pretty consistent: more features, more gamification, more visual noise. Each new version adds another thing competing for your attention inside the very tool you're using to protect your attention.

For neurotypical users, a lot of this probably lands fine. Streaks feel motivating. Badges feel rewarding. The dopamine hit from a completion animation is a nice little nudge.

For someone with ADHD, that same interface is basically a slot machine. Your brain locks onto the wrong thing. The timer becomes secondary to the achievement system. You spend twenty minutes customizing your workspace theme instead of doing the work.

I kept trying different tools. I kept running into the same wall. And eventually I stopped blaming myself for not finding the right workflow and started looking more carefully at what the tools were actually doing to my brain.

Enter My Daughter

The thing that pushed me from frustration to building was watching my daughter try to use a computer.

She has ADHD. She's sharp, curious, and completely derailed by anything that competes for her attention. Watching her try to use any kind of focused app was like watching someone try to read in a room where every surface had a TV on it.

I wanted to find her something that would help. Something calm. Something that would get out of the way and just... hold the space for focus.

I couldn't find it. So I built it.

"I wanted to make a tool that will help my daughter learn to work with computers and her ADHD. The tool that I never had."

What I Actually Built

PomoTok is a pomodoro focus timer for Windows, and its design philosophy is essentially the inverse of everything I just complained about.

The entire interface is a 320×320 pixel floating widget. Warm, earthy colors. No animations. No streaks. No badges. It sits on top of your work, tells you how much time is left, and stays completely out of the way.

The three things I cared most about getting right:

1. Distraction blocking that actually blocks

Most focus apps offer a browser extension. You can disable it in two clicks. That's not blocking — that's a suggestion. PomoTok routes blocked sites through a local system proxy and forcibly minimizes distracting apps the moment they try to steal focus. You set the rules once. The timer enforces them. No honor system.

2. Screen dimming

A full-screen overlay dims everything outside your active window. This one sounds small. It isn't. Peripheral visual noise is a real problem for a lot of ADHD brains — the thing in the corner of your eye that keeps pulling your gaze. The dim overlay just... stops that from happening. It's remarkably effective.

3. No native Electron

PomoTok is a native WinUI 3 app. Not a web wrapper. Not Electron. It starts in under a second, uses minimal resources, and runs quietly from the system tray between sessions. I'm building tools for people who already have enough competing for their attention — the least I can do is not add a 300MB runtime to that list.

What I Left Out (On Purpose)

No social features. No sharing. No leaderboards. No streaks. No achievements. No sound library. No marketplace. No integrations. No premium tier unlocked by daily check-ins.

Session stats exist — daily and weekly charts of your focus patterns — but they're just data. They don't nudge you. They don't shame you. They're there if you want them.

Every feature I didn't build was a deliberate decision. The productivity app space has a habit of treating "more" as the default direction. PomoTok goes the other way.

The Response So Far

I built this primarily for my daughter and for people like us. What I didn't fully anticipate was how many people would immediately recognize themselves in the problem description.

If you've ever felt like productivity software was designed for someone else's brain — you were probably right. PomoTok was built for yours.

Get PomoTok on the Microsoft Store — $5.99, Windows 10 & 11
👉 https://apps.microsoft.com/detail/9N9KMN0VNHRN

PomoTok is made by CHKDSK Labs, a one-person indie studio building privacy-respecting, locally-run tools on consumer hardware.

The Inference Cost Crisis Is Broken — So I'm Building My Own Fix

Jay Grider — Thu, 02 Apr 2026 22:55:15 +0000

Everyone's talking about how cheap AI has gotten. And yeah, on the surface, the numbers look better than they did two years ago. But if you're actually trying to run research, iterate on models, or build something that isn't just a wrapper around someone else's API — the cost picture looks completely different.

I'm Jay. I run CHKDSK Labs, a one-person attempt at a business focused on privacy-preserving, locally-run AI infrastructure and open source tooling. And I've been watching the inference cost problem get papered over instead of solved for a while now. It's all headlines like "DDR5 costs $5 a kb" instead of "Hyperscalers Need to be Held to the Same Optimization Standard as an Indie Game Dev." Honestly you would think Bethesda is behind all this with how much hardware they need.

Here's the thing nobody says out loud: the model improvements and the cost reductions are mostly flowing to consumers of inference, not builders of it. If you want to train, fine-tune, or do serious research — you're still renting horsepower from someone else, at their pricing, under their terms, with your data leaving your machine. That's a fundamental problem if you care about privacy, reproducibility, or just not having your costs explode the moment your experiment gets interesting.

So I started building AAT — Adaptive Architecture Trainer.
The core idea is straightforward: a local-network research platform where a secondary AI Controller autonomously adjusts hyperparameters during training runs, in real time. Not post-hoc. Not human-in-the-loop for every tweak. The controller watches what's happening and adapts. It's the kind of thing that's hard to justify renting cloud GPUs for because the iteration cycles are long, unpredictable, and deeply compute-intensive. It's the kind of thing that makes sense on hardware you own.

I'm not building this to compete with the hyperscalers. I'm building it because the gap between "AI research" and "tools that work on hardware a small team or solo developer can actually own" is embarrassingly large — and nobody seems to be treating that gap as the problem worth solving.

This is the first in what I expect to be an irregular series of posts. I'll write when there's something real to say: architectural decisions, things that broke, things that worked, and the occasional opinion on why I think the current trajectory of the AI tooling ecosystem is leaving a lot of value on the table.

If you're also building local AI infra, working on compressed-compute approaches, or just tired of the cloud-only narrative — I'd genuinely like to hear from you.

CHKDSK Labs is on GitHub.

Introducing L-BOM and GUI-BOM

Jay Grider — Tue, 24 Mar 2026 20:44:01 +0000

The AI software landscape and the broader development communities are in a serious period of change. While one could argue that open-source development has steadily evolved over the last two decades, it would be foolish to not view the current explosion of Large Language Models (LLMs) as an entirely different beast.

If you spend any time on GitHub, Hugging Face, or developer forums today, you are likely witnessing a paradigm shift. We are downloading, sharing, and deploying massive AI models at an unprecedented rate. However, with this rapid adoption comes a significant lack of transparency. When developers integrate .gguf or .safetensors files into their applications, they are often doing so blindly.

This is where the concept of accountability in the modern workspace becomes paramount, and it is exactly why the introduction of L-BOM and its companion, GUI-BOM, is so critical.

The Liability of the Unknown

In any professional field—whether human resources, legal counsel, or software engineering—there are immense liability concerns when operating without full visibility. When a company or an individual developer utilizes an LLM without understanding its underlying components, training data lineage, or structural dependencies, they are taking on unnecessary risk.

Historically, the software industry solved this with a Software Bill of Materials (SBOM) for traditional codebases. Yet, the AI space has remained something of a "wild west." We need a way to ensure that the tools we are using are secure, compliant, and ethically sound.

Enter L-BOM: Strategic Transparency

L-BOM (developed by CHKDSKLabs) is an open-source tool built to tackle this exact problem. It functions as a specialized SBOM generator designed specifically for LLM .gguf and .safetensors files.

At its core, the L-BOM command-line interface acts as a strategic auditor. It parses through these dense, often opaque model files and generates a clear, structured bill of materials. By using L-BOM, developers are no longer blindly trusting black-box files; they are practicing strategic software management. It allows stakeholders to verify what exactly is running under the hood, significantly mitigating potential security and compliance risks.

GUI-BOM: Democratizing the Data

While command-line tools are incredibly efficient for automated pipelines and seasoned engineers, they can sometimes represent a form of authoritarian structure—locking valuable information behind a wall of technical proficiency.

This is where GUI-BOM provides immense value. By offering a graphical interface, it brings a more democratic approach to AI transparency. It allows project managers, compliance officers, and developers who prefer visual workflows to easily inspect the anatomy of their LLMs. It ensures that the vital information regarding model components is accessible to all stakeholders, fostering a culture of open communication rather than siloed expertise.

In Culmination

It is becoming more and more common to see organizations rush to implement AI without fully considering the long-term structural integrity of what they are building. These companies risk failing to cater to the end goals of security and ethical deployment.

Tools like L-BOM and GUI-BOM represent a necessary step forward. They push back aggressively against opaque practices and provide the transparency required to build safe, accountable, and highly productive AI systems.

If you are working with .gguf or .safetensors files, implementing an SBOM generator is no longer just a good idea; it is a professional necessity.

Explore the project and contribute here: github.com/CHKDSKLabs/l-bom
github.com/CHKDSKLabs/gui-bom

The Paradigm Shift of Agentic AI: Iterative Self-Improvement

Jay Grider — Mon, 23 Mar 2026 19:16:52 +0000

The Paradigm Shift of Agentic AI: Iterative Self-Improvement

The software development landscape is in a serious period of change. While one could argue that coding practices had not changed very much over the last decade, it would be foolish to not view their current rate of change with agentic AI as an entirely different beast.

Agentic AI is easily described in tech blogs, inspirational keynote speeches, and short blasts of positivity from engineering managers. But ultimately, its true value lies in its ability to iteratively improve its own capabilities to deliver higher-quality code.

The Functional Nature of Agentic AI

For starters, we can examine the functional nature of how these systems operate. Unlike traditional AI models that wait for a user's prompt to generate a static block of text or code, agentic AI takes on the role of an autonomous helper.

It is easily explained as this: a human developer writes a script, runs it, encounters a compiler error, and spends hours debugging. An agentic system, however, enters a continuous loop of self-correction. It writes the code, tests it against the desired outcome, identifies its own failures, and rewrites the problematic lines before a human ever intervenes. By doing this, the AI is gleaning small parts of feedback from its own environment and gluing that together to find a working solution.

Code Quality and the "Exhaustion Stage"

Next up, we have the impact this has on organizational capabilities and overall code quality. Software development often involves walking a definitively tight line between shipping features quickly and maintaining high technical standards. Human developers are frequently motivated by stress caused by deadlines. While stress can sometimes increase short-term productivity, it eventually leads to an exhaustion stage where the human body and mind begin to break down, resulting in rushed, error-prone code.

Agentic AI does not suffer from the physiological and psychological effects of enduring long-term stress. It can relentlessly review and refine its logic without fatigue. This iterative self-correction results in exceptionally high-quality, secure code.

I view agentic AI as a critical function of the system of a modern engineering team, almost like oil in a car engine. It keeps the system running smoothly without friction.

In Closing

In closing, utilizing agentic AI to iteratively improve its own code creates massive strategic value for an organization. It pulls the practice of software engineering out of the dark ages of manual syntax checking and into the modern world where AI is expected to make proactive contributions to the success of the company. It is not replacing the human element, but rather paving the way for developers to focus on higher-level architecture and mission-aligned work.

Why I Built Ridge Sight: Escaping the Dependabot Tab-Juggling Act

Jay Grider — Sun, 22 Mar 2026 03:56:33 +0000

The modern developer workspace is constantly evolving. While we have more tools than ever to automate our workflows, the day-to-day reality for many of us is often just a chaotic management of browser tabs. If you maintain multiple repositories—specifically a fleet of Next.js projects—you know exactly what I’m talking about.

For starters, we can examine the nature of dependency management. As developers, we're wired to want to keep our apps secure and up-to-date, which is why we lean so heavily on automated tools like Dependabot. However, these tools introduce a unique set of challenges.

If you happen to be managing a handful of Next.js projects, you’ve likely witnessed the overwhelming flood of minor dependency bumps. You open your browser, and suddenly you're forced to flip from repo to repo, org to org, just to verify and merge a simple, straightforward pull request. It’s an incredibly tedious responsibility.

The underlying factors of this frustration are consistent. This constant context-switching acts as a massive stressor, pulling you away from meaningful work and forcing you into the role of being a paper-pusher for automated bots. I viewed this process as a critical flaw in my own system. The fact that a simple, centralized view for this specific problem wasn't readily available was in and of itself the largest challenge.

This is exactly why I built Ridge Sight.

Ridge Sight is designed to centralize pull requests into one single dashboard. Instead of accepting the disorganized, laissez-faire reality of standard GitHub notification feeds, I wanted a tool that provided clear, actionable deliverables. Ridge Sight pulls everything into one place so you don't have to play the tab-juggling game just to merge a minor dependency update across five different projects.

Beyond this, Ridge Sight helps to align your daily functions more with your actual strategic goals: writing code and building great products. Working in software development has a unique set of challenges, but managing routine PRs shouldn't be the most exhausting part of your day.

If you're tired of the constant repo-flipping and want to bring some much-needed focus back to your workflow, I'd love for you to check out Ridge Sight and let me know what you think!