Fretscape started because my daughter Isla, nine years old, got frustrated trying to play on my old full-size PRS.

The obvious answer was practice more. The honest answer was the tool's wrong, not you. So I started building a different one.

That's the origin story in three sentences. This series is about what happened next.

What this is

Five short stories. Each one is about a specific decision I made while building Fretscape - usually a moment where the easy answer and the right answer pulled in different directions and I had to pick.

Some of them touch on chord theory. Some touch on how the optimiser ranks voicings. All of them are written for guitarists, not engineers. You won't need to know how anything is implemented to follow along.

If you build products, you'll recognise the decisions even if you don't play guitar. The shape of "the cheap answer is right there, take it" doesn't really care what industry you're in.

Technical doesn't have to mean inaccessible. I promise.

The thing they all have in common

Every story in the series starts the same way.

The system did something technically correct. And it felt wrong.

The easy thing to do is shrug. Well, it's valid. Move on. The harder thing is to stop, figure out why it feels wrong, and encode the missing rule. I've gone with the harder one every time. The whole product is shaped by that choice.

Technically correct isn't the same as helpful.

That sentence is the whole product compressed. Everything in the series is a different version of working out what it means in practice.

Looking back, that might be the real theme of this series. Not cleverness. Restraint.

It is easy to build a tool that always gives an answer. It is harder to build one that knows when the answer is incomplete, or context-dependent, or only technically correct. Harder still to show that uncertainty to the user instead of smoothing it over with a confident-looking label.

But that is where the useful bit lives.

Why "every hand"

Fretscape's pitch is guitar for every hand.

That's not abstract. It means the tool rebuilds itself around whoever's playing - beginner hands, missing-finger hands, small hands, tired hands, hands recovering from an injury, hands with arthritis. A tool that treats every hand the same is serving none of them.

The ethos of "the right answer for this person" isn't a value statement. It's the whole design.

That's also the reason "technically correct" isn't enough. A correct answer that doesn't fit your hand isn't the right answer for you. It's the right answer for someone you don't happen to be.

The series

I Built a Chord Optimiser That Proved Me Wrong - A fingering I was sure Fretscape had got wrong. It hadn't.

The Optimiser That Was Quietly Ignoring Me - Three bugs in the progression optimiser, found while taking a screenshot. Features a car salesman.

Technically Correct Isn't The Same As Expected - Two voicings that were theoretically right but not what a guitarist expects to see first.

The Wrong Name, Ranked First - Why a reverse chord lookup can rank a valid-but-wrong name above the obvious one, and how Fretscape orders it differently.

What Key Is This Progression Actually In? - Why Fretscape returns calibrated confidence rather than confident-looking match scores, and why ambiguity is sometimes the honest answer.

Five different surfaces of the product. Same decision, made five times.

How to read it

If you want to know how Fretscape thinks, the five posts above will show you.

If you want to feel how Fretscape thinks, use the app. Both are free to start.

These are small stories about small decisions.But small decisions are the product.

Thanks for reading.