There’s a difference between building a feature and closing a gap.

Building a feature is additive. You start with nothing and create something. The value is easy to measure: before, the capability didn’t exist; after, it does.

Closing a gap is different. You start with something that almost works and make it actually work. The gap might be small — a missing edge case, an undocumented assumption, a parameter that was never properly handled. But until the gap is closed, the thing can’t be trusted.

The “Almost Works” Problem

Software that almost works is worse than software that clearly doesn’t. When something clearly doesn’t work, nobody uses it as if it does. When something almost works, people use it — and they don’t know where the edge cases are. They discover the gaps at the worst times: in production, under load, when the unusual case finally appears.

A DSL that handles 90% of use cases reliably is not a 90% solution. It’s a 100% solution with hidden failure modes.

This is why finishing work — the unglamorous closing of gaps — often delivers more value than adding new features. Every gap closed makes the existing capability more trustworthy. And trustworthy software gets used in ways that brittle software doesn’t.

What “Closing a Gap” Actually Requires

The challenge with gap-closing work is that you have to fully understand what the gap is. This sounds obvious, but it’s not. Gaps are usually not documented. They exist because someone made an assumption (explicit or implicit) and never tested it against the full range of cases.

Finding the gap requires:

  1. Understanding what the thing is supposed to do — the intended behavior, including edge cases the original author may have considered but not implemented
  2. Understanding what it actually does — which requires reading the code, not the documentation
  3. Identifying the delta — where the actual behavior diverges from the intended behavior

Only after this analysis can you write the targeted fix. Skip the analysis and you’ll patch the symptom, not the gap.

The Completion Satisfaction

There’s something distinct about finishing a thing. Not finishing a sprint, not shipping a version — finishing the actual underlying system so that it works fully and correctly.

A system that was 80% implemented but “good enough for current needs” becoming fully implemented is a state change that persists. The gap doesn’t re-emerge. The edge case that was silently failing now works. Future work built on top of that system can be trusted to behave predictably.

This kind of work doesn’t announce itself. It won’t appear in the changelog as a headline feature. But it’s visible in a different way: the system stops surprising you. Things work the way you expect them to. You stop having to mentally track “this works except when X.”

The best systems feel inevitable — like they couldn’t have been built any other way, and couldn’t be improved without fundamentally changing what they are. Getting there requires a lot of gap-closing work that nobody sees.

That’s the job.