The first time you don't have to stop

There's a decision that gets made in almost every product sprint I've ever been part of.

Not out loud. Not in a meeting. It happens quietly, when someone looks at what's been built and asks — consciously or not — is this good enough to ship?

And the answer, most of the time, is yes. Not because it's finished. Because the next thing needs the time more than this thing needs another round.

That was the discipline. Good enough and shipped beats perfect and not live. I believed it. I still believe it — as a starting principle. But it was always a compromise. A rational response to a scarce resource. You'd do two rounds of feedback, get something to acceptable, and move on. The polish — the third round, the fourth, the thing that takes something from good to genuinely right — that got cut. Not because nobody cared. Because the economics didn't justify it.

AI coding tools changed that calculation. Not because they make you faster. Because they let you keep going. AI-assisted development changed the economics of polish — that's the part most teams miss. AI for product managers changed the prioritisation question from "what fits?" to "what's right?"

What "one more round" actually costs

In a team with finite engineering capacity, every decision to polish something is a decision not to start something else. The prioritisation meeting isn't just about what to build — it's about what level of finish each thing gets. Ship it now, or spend another week making it right.

Most things got shipped. The polish got deferred. And deferred polish has a way of never arriving — because by the time you circle back, there's already a new queue of things that need to be acceptable.

I spent twenty years making that call. In GTM teams feeding into product. In product and growth teams making sprint decisions. The pattern was consistent: two rounds of feedback, ship it, move on. The extra mile was a luxury reserved for the most visible, most critical surfaces. Everything else lived at acceptable.

What I didn't fully appreciate until I started building Circuit was how much of the product experience lives in the things that never got the extra mile.

What the git history actually shows

I can tell you exactly how much polish happened building Circuit, because the commit history doesn't lie.

The single most-changed file in the entire codebase is globals.css — the design system. Over 400,000 lines changed. Thirty-eight commits. Every time I went back and looked at the product with fresh eyes, something in the design tokens, the spacing, the variables, the "Quiet Confidence" aesthetic I was trying to build — something was close but not right. So I fixed it.

In a sprint-based team with a prioritisation meeting, most of those commits never happen. You ship the design system at version one. You note the inconsistencies. You add them to the backlog. You move on.

The Brief Panel — the core "Specs out" experience, the thing Circuit is fundamentally built around, went through eighteen rounds of refinement. Section-level refresh. Version toggle UI. Markdown rendering. Status displays. Each one a small commit fixing a specific thing that wasn't quite right.

The login page went through fifteen rounds. The login page. The thing every product treats as an afterthought because there are always higher-priority things to build.

Not here. Not when the constraint changed.

I stopped asking is this good enough? and started asking is this right? Those are different questions. The first is about clearing the bar. The second is about actually finishing something.

The constraint AI coding tools actually changed

When AI coding tools entered the picture, the economics of polish shifted. AI product management raises the ceiling on what counts as finished.

The extra round that used to cost a sprint now costs an afternoon. The fourth pass that used to mean deprioritising something else now means staying an hour later. Claude Code feedback loops are tight enough that one polish round costs an hour, not a sprint. The gap between acceptable and right — which used to be measured in engineering weeks — collapsed.

And when that gap collapsed, something changed about how I related to the product.

I stopped asking is this good enough? and started asking is this right? Those are different questions. The first is about clearing the bar. The second is about actually finishing something.

The login page got twelve rounds not because I kept making mistakes, but because each round of polish revealed the next thing worth fixing. The dark mode had an edge case. The OAuth error handling wasn't clear enough. The email validation needed a better pattern. None of these were critical. All of them made the experience measurably better. And now — for the first time in my career — there was no meeting deciding they weren't worth the time.

The number that surprised me

Here's the detail that still catches me when I think about it.

Of all the code that existed in Circuit's codebase in November 2025, only about 25% remains today.

Not because the early work was wrong. Because iteration, polish and better tools meant I kept finding cleaner ways to do the same thing. The product got smaller and tighter as it got better. The codebase that exists now is a refined version of the one that existed then — not the same thing with more added on top, but something that went through enough rounds of rethinking that most of what was there at the start has been replaced by something better.

That's not rework. That's what happens when you don't have to stop at acceptable.

There's another number that tells the same story differently. In November — the first month of building — 38% of the code I wrote is still in the codebase today. By March, that number is 87%.

Not because the early work was wrong. Because I kept going until it was right. The keep ratio went up as the product got cleaner. Most codebases accumulate technical debt over time — they grow by addition, layers on layers, earlier decisions calcifying into constraints. This one got leaner. Each month, more of what got written stayed, because there was less need to go back and replace it with something better.

That's what "finished" looks like in the data.

In a previous world — a sprint-based team, a prioritisation meeting, finite engineering capacity — you stop when you hit acceptable. You ship. You move on. The code from November would still be there, because there was never time to replace it with something cleaner.

The 75% that's gone isn't technical debt that got cleaned up. It's polish that got done.

What this means for the product experience

The surfaces that matter most in any product are rarely the ones that get the most attention in sprint planning. Polish is the work after the work — and it never got the time it needed under finite engineering.

The login flow. The empty states. The loading indicators. The error messages. The transitions between screens. The copy on the button that nobody reads until they need it. These are the things that get two rounds of feedback and then get shipped, because there's always something more important claiming the next sprint. Spec-driven development works at this granularity too — small fixes get small specs, shipped same day.

They're also the things that quietly shape how a product feels. Not the headline features. The finish. Product instinct stops being a luxury when the cost of one more round drops to an afternoon.

I spent more time on Circuit's design system than on any single feature. Not because the design system is what users see — they don't. But because it's what everything else is built on. Get it right and every surface benefits. Leave it at acceptable and every surface carries that compromise.

Thirty-eight commits on globals.css means thirty-eight times I looked at the product, noticed something that wasn't quite right, and fixed it. That's not excessive. That's what it takes to build something that actually feels finished.

The "good enough" principle, revised

I still believe good enough and shipped beats perfect and not live. That principle hasn't changed.

What changed is where the ceiling is.

In a world of finite engineering capacity, acceptable was often the practical ceiling. You could aim higher, but the economics pulled you back. The third round of polish was a trade-off against starting the next thing.

In a world where AI coding tools have changed the build economics, the ceiling is higher. Not infinite — there are still decisions about what's worth the time. But the gap between acceptable and right is smaller, and crossing it costs less. Which means more products can actually be finished, rather than shipped and left at the first version that cleared the bar.

The discipline isn't "ship it before it's ready." It's "don't stop before it's right."

I built Circuit to the standard I always wanted to build to. Not because I had more time, or more resources, or a bigger team. Because for the first time, the extra mile was within reach.

What's possible when you build past good enough

Here's what I'd tell someone starting to build with AI coding tools for the first time:

Don't just use them to build faster. Use them to build better.

The speed is real, and it matters. But the more interesting change is what becomes possible when you can keep going past acceptable. When the login page can get twelve rounds instead of two. When the design system can be refined until it's actually right, not just consistent enough.

The products that will stand out in the next few years won't just be the ones that shipped fastest. They'll be the ones that finished properly. That went the extra mile not because they had to, but because they finally could.

Good enough got us here.

The next generation of AI-native product development won't stop there. AI product, properly finished, looks different from AI product shipped at acceptable. The question isn't what to build next — it's whether to keep finishing what's already shipped.

---

Catherine Williams-Treloar is the founder of Circuit — the AI product system that turns customer feedback into scored priorities and build-ready specs for Cursor and Claude Code. She has 20+ years leading product, insights, strategy and GTM at scale-ups and enterprises. Circuit was founded in Sydney in November 2025 and launched in February 2026.