How I try to balance shipping with polishing

The other day I saw a very funny meme. It was a picture of a parrot with the caption: "parrot learns how to say 'it depends' and becomes a senior software engineer."

I laughed because it’s actually true. With a bit more experience, you realize that “it depends” isn’t just a cop-out. It’s often the most honest answer. Nobody likes working with someone who’s always saying “no,” “can’t do that,” or constantly throwing up roadblocks. But part of our job is exactly to translate these roadblocks, technical debt, or edge cases into plain language. Make it understandable. Break it into doable steps. Align everyone.

When you know how to do that, your team moves faster. Everyone understands the path. And deadlines, even if no one likes them, become more realistic (which is a whole other post).

I try to learn from everyone I work with, and the best managers and engineers I’ve worked with all have one thing in common: they know how to balance net new work and improvements.

And since I love frontend, I’ll bring the topic there.

The list of things we need to care about in FE is huge. But just to name a few (in no particular order):

Net new stuff: fresh features, new components, setting up a flow from scratch.
Polishing: spacing, alignments, animations, color contrast, keyboard nav. The kind of stuff that no one notices directly, but definitely feels.
Upgrading packages: keeping dependencies clean, trying new versions, avoiding tech debt.
Refactoring components: breaking things up, simplifying props, improving reuse.
Removing dead code: weirdly therapeutic.
Improving performance: faster loads, fewer layout shifts, smoother animations.
Accessibility tweaks: making sure more people can actually use what you built.
Documenting patterns: even a small comment explaining why a decision was made can save a future dev’s day.

And the more I write, the more I remember things engineers need to think about.

The kind of engineer I try to be is someone who ships but also cares about everything else on that list. You’ve probably seen versions of this quote before, but it’s true: ship things or die. That applies to every company. In startups, it’s even more critical.

At the same time, if you never pause to polish, improve, or refactor, your software will turn into a mess.

Should there be a fixed split between the two? Like 70% shipping, 30% polish? I don’t think so. I’ve never found a clean formula that works. The best teams I’ve worked with treat features and deadlines as evolving things. You ship, you iterate, you improve.

Let’s use something very frontend-y as an example: a new table component to display some user data.

How do you ship it? (Don't read the rest, really think about it for a min)

--
---
----
-----
------

Here’s how I’d break it down:

Raw table with real data. Basic layout and styles to match the app, plus basic accessibility. Tag it "beta" if you need.
Add loading states, empty states, error handling.
Add sorting, filtering, and pagination.
Then the polish: spacing, alignment, row hovers, maybe an animation or two.
Then better accessibility: keyboard navigation, labels, screen reader support.
Finally: refactor to make it reusable if needed, and add docs.

At every step, it’s usable. You’re not waiting to perfect it. You’re giving value early and then layering improvements.

This is the rhythm I try to follow: build, ship, improve.

You don’t have to pick between speed and quality. You just need to know when to switch gears.

This way of thinking has helped me stay motivated and productive without burning out. Some days I just want to ship something new and feel that momentum. Other days I get obsessed with making a button animation feel right. Both are valid. Both matter. And honestly, the most incredible people I’ve worked with do exactly that, this is not my idea. It’s just something I’ve picked up from the pros over time.

If you're working on a product, you probably already feel this tension between speed and quality. My advice is to stop seeing them as opposites. They can (and should) live together.

Not every release needs to be polished. Not every improvement needs to wait for a sprint.

Balance is about knowing when good enough is truly enough and when something needs that extra 10% to feel right.

If you’ve read this far, I’m curious: how do you approach this? How do you and your team balance shipping vs improving?

Thanks for reading!