Hello

Hello

The Plan Was To Make Music

Hey, my name is Eshaan Sood. I am a musician who happens to be blind, and somehow over the last year I have also become the kind of person who has opinions about CRDTs, accessibility trees, terminal rendering loops and whether a dependency has enough people maintaining it. This was not the plan.

The plan was to make music.

In February 2025, I was about to record my first full-length album and I did not have a website. I also did not have the money to record the album, so hiring someone to make the website was not exactly on the cards. This is very funny to me because I was not some person who had never cared about technology. I got my first PC in 2003 when I was 8. I learnt how to make games run on whatever sad little machine I had at the time. Floppy disks, burnt CDs, RAM upgrades, GPU upgrades, jailbreaks, hacks, mods, all of it. If there was a way to make a piece of technology work better, I was going to try it.

Then I went blind at 20 and a lot of the technology I loved regressed many layers overnight.

Sublime Text, which I used for basic HTML, still does not work properly with my screen reader. Free website builders were not blind-accessible. Terminal workflows were technically available, but garbage to use. So I did what every broke musician does and asked a friend for a favour. My friend Aadhithya Kota built me my first personal website .

That worked until it didn’t. A bio edit here, a tour date there, a press contact, a small feature, another small feature. Asking for a favour every weekend is not a system. It is just guilt with extra steps.

The Door Opened

That is how I started using AI tools to edit my own website. At first I did not trust any of it. I would prompt, inspect, manually commit and push. Nothing went live unless I had at least some idea of what changed.

Then curiosity did what curiosity does.

I had a documentary for my album and wanted dynamic content to scroll below it as the video played. I did not know if this was possible. Turns out HTML5, a Vimeo timestamp and a JSON file can take you pretty far if you are willing to break your head against the problem for ten days. That became the Dream River documentary site .

After that came the Dream River mini-game . People could sign up, pin themselves on a globe, share the album with friends, earn points and unlock rewards. That one taught me about node graphs, Three.js, databases, auth, backends, caching and interpolation. None of these were terms I understood before I started.

This is basically the origin story of Blinding Pixels.

Not Magic, Just Leverage

I am not a software engineer. I am a very curious musician. I do not think AI magically makes everyone a developer. That is hype train nonsense. There is some truth in it, but the best lies usually have some truth in them.

What AI did for me was open a door. Walking through the door still meant learning enough to not immediately fall down the stairs.

You cannot just say “fix bug, build feature, make no mistakes” and expect anything useful to come out the other end. I know this because I have done it enough times. If you ask a child to follow a Beef Wellington recipe and they do not understand half the words in the recipe, you are not getting Beef Wellington for dinner that night.

So my whole process became learning enough to inspect the work.

Not enough to cosplay as a senior engineer. Not enough to pretend I am suddenly a Rust wizard. Enough to ask better questions. Enough to know when something smells wrong. Enough to read a ten-line file and understand what goes in, what comes out and whether anything is quietly leaking into the floorboards.

Learning To Hear The Playback

That matters because code does not play its own guts out loud.

In music, if I write something for a cellist, the cellist cannot secretly turn my part into a totally different structure without me hearing it. The notes are the notes. But software can sound exactly like what I asked for and be built wrong underneath. A clanker can hand me something that works on the surface and is quietly doing the dumbest possible thing under the hood.

So I have to learn to hear the playback differently.

This is why I care so much about accessibility-first software. Not as a decoration. Not as “add some labels at the end.” Accessibility has to exist in the architecture. Swift and Mac accessibility taught me this very clearly: if the access layer is declared deep enough in the model, everything above it inherits the benefit. If you bolt it on at the end, you spend your life fighting the shape of the thing.

That idea now sits underneath most of what I build.

What I Build

Sometimes that means a music notation experiment because I wanted to make charts without sighted software getting in the way. That became the Living Score Parser Demo.

Sometimes it means a local-first encrypted productivity app because my life has too many projects and my tools are either inaccessible, too expensive, too cloud-dependent or all three.

Sometimes it means looking at a terminal, a document editor or a game interface and asking: what would this look like if access was not an afterthought? That thread runs through the Ghostty VoiceOver Accessibility Fork, the iOS Gesture Input Demo, and the Accessible Hyper-Twister Builder.

The Rule

I still live by one rule: I don’t know anything.

No matter how much the model tries to glaze me, no matter how many times it calls something a sharp observation, no matter how revolutionary it says the idea is, I still have to assume I am missing something.

That rule has saved me more than once. It makes me check dependencies. It makes me read docs. It makes me ask another model to translate the jargon into plain English and then poke holes in that explanation until it stops wobbling.

The advantage of being a normie in code is that I have no sacred language war to fight. I do not care if the answer is TypeScript, Swift, Rust, Zig or something else. The language should serve the product, not the other way round. You can play funk on a ukulele, sure, but why make your life harder on purpose?

The other advantage is domain expertise. I am blind, so when I work on accessibility, I am not guessing from the outside. I am a musician, so when I work on music tools, I know what the actual shape of the problem feels like. That does not replace engineering knowledge, but it does give the work a reason to exist.

Blinding Pixels

Blinding Pixels is where I put that work: products, experiments and research projects made from accessibility-first principles.

It is also a place to be honest about what it looks like when a blind non-developer tries to participate in building software without pretending the tools are magic.

That is the whole thing really. I am making the tools I wish existed, learning enough to inspect what I am making, and trying very hard not to confuse access to leverage with actual knowledge.