RSS Amplifier

Balint’s Newsletter · Jun 18, 2026

The standard you set when no one's watching

0
Sign in to vote or save

This page did not load. You can still read it on the original site — the toolbar below keeps your place in the directory.

The gap between acceptable and memorable usually lives in the moments you could have skipped.

I’ve been thinking about the difference between a product that feels considered and one that just... works.

Both ship. Both close tickets. Both get approved in review.

But one of them has this quality where you’ll use it for six months and then notice something small. A tooltip that’s actually helpful. A confirmation message that doesn’t sound like it was written by a lawyer. And you stop for a second and think: someone thought about this moment.

That feeling is rare and I don’t think it’s rare because caring is hard. I think it’s rare because the moments that create it are very easy to skip.

The work that doesn’t have a ticket

Every project has two kinds of unfinished work.

We’re pretty good at pretending the second kind doesn’t exist.

The first kind is easy to see: the backlog, the roadmap, the things users are actively complaining about. There’s accountability for these. They get done.

The second kind is quieter:

  • The error state nobody ever designed properly

  • The edge case that affects maybe 3 percent of users and technically works but doesn’t make sense

  • The thing that’s slightly off in a way that’s hard to file as a bug but everybody on the team notices when they use the product themselves

Most products ship when the first kind of work is done. The second kind just lives there, quietly accumulating.

I used to think this was a prioritization problem or a resource problem. Now I think it’s more of a habit problem.

The skeleton everyone knows about

Most teams have at least one thing where everyone quietly knows it’s not right. You see it in every demo. You see it in every review. When you open the product yourself, you mentally skip past it because you’ve made peace with it being there.

And the strange thing is, it’s usually not that hard to fix. The reason it sticks around isn’t lack of skill or time. It’s that fixing it has to come from inside. No one’s going to put it in a sprint. No user complaint will force it onto the roadmap. The only reason to fix it is that you decided it isn’t done yet.

That’s a harder decision than it sounds. Especially when shipping something new feels more productive than going back to something that already works well enough.

Care as a reflex, not a trait

I used to think people who cared deeply about craft were just built that way. Either you notice when something’s slightly off, or you don’t.

I don’t think that anymore.

What I’ve noticed is that it’s more of a reflex. And reflexes either get reinforced or they erode. Every time you catch something that’s slightly wrong and fix it anyway, you make it a little more likely you’ll do it again next time. Every time you catch it and walk past, you make walking past a little easier.

Over a year or two of building something, those small decisions compound into the difference between a product that feels made and one that feels assembled.

This matters more now, not less

When decent quality is easy to produce because the tools are better and faster, the products that feel genuinely considered stand out more. Not because they’re technically impressive, but because they’re evidence someone was paying attention.

What this looks like in practice

Before you close a project or ship something, ask yourself one thing: what’s the part I know isn’t right that I haven’t fixed because nobody asked me to?

Not a missing feature. Not an item in the backlog. The thing you notice when you use your own product and quietly think “that’s a bit off.” The thing you’ve made peace with.

In my experience, that thing is almost always smaller than it feels. It takes less time to fix than the mental load of knowing it’s there. And fixing it tends to recalibrate how you look at everything around it.

There’s also a softer version of this that has nothing to do with bugs or polish. Sometimes it’s just asking whether you’ve been present enough. Whether you sat with what you were building, used it yourself, handed it to someone you respect and watched them use it without jumping in to explain things.

That kind of attention is harder to schedule than a design review. It’s also where most of the real observations come from.

The thing about “good enough”

I want to be careful here, because not everything needs more attention. Knowing what to leave alone is as useful as knowing what to fix.

But there’s a version of “good enough” that’s a real quality judgment, and a version that’s just a decision to stop looking. Most of the time when I hear people say something is good enough, they mean the second one.

The products I keep coming back to, the ones I actually recommend to people, almost all have something in common: somewhere in them, someone stayed with it a little longer than they had to.

You can feel it in places you didn’t expect.

A detail that didn’t need to be there. A decision someone made that wasn’t in any spec, because it was obviously right and so they just did it.

That’s the work nobody asked you to redo.

The problem nobody would have blamed you for leaving alone. And those are the moments that actually define what a product is.


Thanks for reading :) If something in this issue resonated, please reply and tell me.

Even one line. These replies are my favorite part of writing this newsletter.

See you next Thursday 🙌

— Balint


What else I’m working on?

Check it out


Thanks for reading Balint’s Newsletter! Subscribe for free to receive new posts and support my work.

Read on balintbogdan.substack.com

Comments

Nothing yet. Say the first thing.

    Sign in to join the conversation.