👷 How to Finish Early and Satisfy your Stakeholders
This is how I ship projects when they are good enough and move to the next thing faster than other engineers.
I was in my early twenties, still in university university, and responsible for a handful of client projects at my first real job. I had been coding since high school and I thought I knew what good work looked like.
I added key bindings to a jov board website. The client ran a small recruitment agency. Nobody on their team had asked for it, and nobody ever used it but I spent a week on it.
Projects ran late, budgets inflated, and our clients got angry. My boss, instead of firing me, handed me a small stack of books. In one of these books, The Pragmatic Programmer, I read about a concept I had never considered: shipping code that is good enough.
That idea rewired how I work. It changed how I ship, how I grow, and how I think about what it means to be a good engineer. I have spent years since then watching talented senior engineers repeat the same pattern I had at 21, and lose the same things I lost: time, trust, and the opportunity to work on harder problems.
Perfectionism Is Not About Bugs
You should never deliver buggy work intentionally. That is not the argument here, and I want to be clear about it before going further.
Most of the work engineers do past the point of “done“ falls into one of two buckets.
The first is rough edges. All sorts of imperfections that exist in the product but that no real user will ever notice or care about fall in this bucket. Think about a column name that is slightly inconsistent with the naming convention elsewhere, or query that runs in 800ms when it could run in 200ms, on a report that gets opened twice a week.
The second bucket is design preferences. These are things you want differently that your stakeholder never asked for, like a cleaner folder structure in the repo, a more elegant solution to a problem the current solution already solves.
The Distinction That Changes Everything
Rough edges and design preferences get presented as quality standards. That is the trap. An engineer tells themselves they are maintaining high standards when they are spending an entile afternoon on a naming convention nobody will audit.
Intentional restraint is a design decision. Choosing not to smooth a rough edge because no user will ever hit it is not laziness, and choosing not to build the abstraction because the requirement does not exist yet is not cutting corners. These are scoping decisions, and good engineers make them on purpose.
The engineers who struggle to stop are not the ones with low standards. They are the ones who have never separated “complete in my head“ from “complete for the purpose it serves“.
Perfectionism Costs More Than You Think
Shipping on time builds something you do not think about in the moment: a track record of reliability.
Your stakeholder remembers two things about you:
whether your work was good
whether you delivered when you said you would.
The second one compounds faster than the first.
When you ship clean, scoped work on time, you get the next project. And, you get pulled into the room where the decision is being made, because someone already knows you can be trusted to close things out.
That is the return on shipping. It is not glamorous, but it is how careers actually move.
Your career is not stuck because you lack technical skills.
It is stuck because nobody taught you how to operate. Stakeholder management. Business translation. Career positioning. I write about all of it every week
The Week You Think You’re Investing
When you spend an extra week polishing past the agreed scope you lose:
the relationship capital that week would have built with a different project
the harder problem waiting on the other side of this one closing
the visibility that comes from being someone who finishes
The cost disappears into the background noise of a slow quarter, and you never connect it to the week you spent on a naming convention nobody audited.
What You Actually Buy With That Extra Week
Polish on a finished product does not teach you anything new. It does not stretch your judgment or expose you to problems you have not solved before. It has the texture of diligence without the substance of it.
Perfectionism Is an Identity Problem
Here is what I have never heard a perfectionist engineer say: “I know this is done, I just cannot stop“.
They do not say it because they do not believe it. Every rough edge they are smoothing feels critical, and every design preference they are implementing feels like a quality standard.
The rationalization runs underneath the decision, and it sounds like judgment.
Where the Identity Comes From
At some point early in your career, you built an equation: good engineer equals engineer who finishes everything.
You saw thoroughness rewarded. You also got praised for catching edge cases, for going deeper than required, for the extra mile. The identity formed around completion.
That equation made sense then. In the early stages of a career, thoroughness is how you signal competence. You do not have a track record yet, so you demonstrate care through the detail of your work.
The problem is that the equation does not update. Ten years later, you are still running the same calculation, in a context where finishing the right things matters more than finishing everything.
What the Research Says
Psychologists separate perfectionism into two types.
Adaptive perfectionism: high standards, strong execution, healthy relationship with finishing.
Maladaptive perfectionism: the same high standards, but fused with avoidance, procrastination, and an inability to call something done.
The difference is what happens in your head when the work is good enough but not perfect.
A 2021 meta-analysis found that adaptive perfectionism is associated with better performance and wellbeing, while maladaptive perfec tionism is associated with worse wellbeing, more procrastination, and avoidant coping.
Most engineers I know with this pattern are maladaptive perfectionists. I was one, too.
The Gap Between Knowing and Shipping
There is a moment every over-polishing engineer knows but rarely names. The product works. The stakeholder is happy with what they have seen. The agreed scope is complete. And you are still in the code.
You know you are done. You stay anyway.
What fills that gap is the discomfort of letting something exist in the world that is not complete in your head. Shipping means accepting that the version in production will always be slightly less than the version you imagined.
For an engineer whose identity is built around completeness, that feels like becoming a lesser version of yourself.
That is the thing a productivity tip cannot fix. You need a different answer to the question of what a good engineer actually is.
The Stakeholder Already Told You It’s Done
Most engineers treat “done“ as a technical state. The data product reaches some internal threshold of completeness and then it ships. The problem with that definition is that you set the threshold, and you will keep moving it.
Done is an agreement.
You and your stakeholder defined the scope before the work started. They tell you what they need, and you build it. At some point in the review process, the nature of their feedback changes.
Early feedback sounds like “can we change how this filter works“ or “the numbers on this chart do not match what I expected“. That is active problem-solving.
Then the feedback shifts:
“This looks great, when can we roll it out?“
“When I can get access to this?”
“Can the we also give access to my team?”
This shows you that your stakeholder has stopped looking for gaps and started thinking about using the product. The agreement has been reached.
The Closing Question
Questions like “is there anything you’d like to improve“ or “are there any other features you’d find useful invite scope expansion and put you back at the beginning of the loop. Stop asking them.
Before you hand anything over, ask one question: is there anything critical missing?
The word critical does the work. It filters out preferences and surfaces only the things that would prevent the product from serving its purpose.
If the answer is no, you are done. Write it down, send it in a message, create a paper trail. That record is for you as much as for them.
When You Talk Yourself Out of the Signal
“They said it looks great, but they have not stress-tested it yet.“
“The feedback was positive, but that was on the easy use case.“
“I should add one more thing before it goes live, so the first impression is better.“
Each of these sounds reasonable. None of them are about the product. They are about the discomfort of letting go, but the stakeholder told you it is done.
You already know the problem. You have known it for months.
The gap between "knowing what to do" and "doing it" is just a decision. Inside the paid tier you get the frameworks, scripts, and templates I used to build my career over 16 years. Field-tested stuff!
Bugs, Rough Edges, and Design Preferences Are Not the Same Thing
The “one more thing“ feeling always presents itself as necessary. That is what makes it hard to dismiss, and that is exactly why you need a framework for categorising what you are looking at before you act on it.
Bugs
A bug prevents the product from doing what it was agreed to do:
A pipeline that drops rows under certain conditions
A report that breaks when the date range crosses a month boundary
A metric that calculates correctly in the dev environment and incorrectly in production.
Defects are non-negotiable. Fix them before you ship, and if you find them after you ship, fix them immediately. This is the category that justifies stopping the clock.
Rough Edges
A rough edge is an imperfection that exists outside any real user’s path:
A column name that deviates from the naming convention in a table nobody joins to directly
A query that runs in 900ms when it could run in 150ms, on a dashboard opened twice a week by one analyst
A tooltip with slightly imprecise wording on a filter that experienced users skip entirely.
Rough edges are invisible in practice. Leaving them is a scoping decision made on purpose, based on actual usage.
“Ugly by design“ is a legitimate engineering position. It means you looked at the imperfection, assessed its real-world impact, and decided the cost of fixing it outweighs the value.
Design Preferences
Design preferences are the expensive category, because they are the hardest to recognise in the moment.
A design preference is something you want differently that your stakeholder never asked for:
A cleaner abstraction that would make future changes easier, for a future with no confirmed date
A folder structure that better reflects your mental model of the system
A more elegant solution to a problem the current solution already solves.
The test is one question: did anyone ask for this, or does it exist because it is incomplete in your head?
If the answer is the second one, you are looking at a design preference.
The Post-Launch Contract
Shipping is not abandonment. Your stakeholder needs to know what happens after the product goes live, and that conversation is your responsibility to initiate.
Most engineers skip it. The product ships, the Slack message goes out, and everyone moves on with an implicit assumption that the engineer is available for whatever comes next. That assumption becomes a maintenance burden with no defined edges, and it will pull you back into the product indefinitely.
Define the edges before you ship.
What You Commit To
Two things:
First, if something breaks in a way that prevents the product from doing its job, you fix it. A bug that surfaces post-launch is still a bug.
Second, you will check in proactively after two weeks to ask whether the product is working for them and whether anything critical is missing.
That check-in matters more than most engineers realise. It signals that you care about the outcome, keeps the relationship warm, and gives your stakeholder a defined moment to surface real issues. It also gives you closure.
What You Do Not Commit To
Everything outside those two things goes into a backlog. Feature requests, aesthetic preferences, and optimisations that would be nice to have are legitimate inputs for a future iteration, and you should capture them.
They are worth doing if the product sees real usage and the stakeholder comes back with them after living with the tool for a while.
A short message after launch that outlines what you are monitoring, when you will check in, and how to flag something urgent. Two paragraphs are enough.
The goal is a shared understanding, not a formal document, slides or any other corporate bullshit.
Why This Protects the Relationship
A stakeholder who knows what to expect from you after launch trusts you more. The engineer who disappears after shipping and the engineer who commits to everything indefinitely both damage the relationship in different ways.
Defining the post-launch contract is what makes you someone worth working with on the next hard problem.
You Will Know If It Works
Two weeks after launch, you have access to something more reliable than your own anxiety: data.
Data products leave traces:
Every query run against your pipeline shows up in query history
Every dashboard opened appears in your BI tool’s usage logs
Every tab viewed in a shared Google Sheet is recorded in the Activity Dashboard
You do not need your stakeholder to tell you whether the product is being used, because you can look.
This matters because the fear that drives post-launch anxiety is usually vague:
“What if something is wrong?“
“What if they are not using it?“
“What if I missed something?“
These are discomfort dressed up as diligence. The data answers them directly, and the answer is almost always that the product is running, people are using it, and nothing is on fire.
What to Look For
Query history tells you whether the pipeline is being hit and at what frequency. A product that was supposed to run daily and shows seven consecutive days of successful runs is a product that works
If the usage logs show nothing, that is information too. A product nobody uses is a product worth a conversation with your stakeholder, and that conversation is more useful than another week of polish would have been.
The Check-In
At the two-week mark, send a short message. Ask two things: is the product working for them, and is there anything critical missing.
The same question you asked before launch, asked again with two weeks of real usage behind it.
Most of the time the answer is positive. Occasionally something surfaces that genuinely needed addressing, and you address it. Either way, you now have a closed loop.
The product is no longer an open question sitting in the back of your head. You can move on to the next problem without carrying it with you.
Final Thoughts
The way you write code has changed. AI writes a significant portion of it now, which means the craft argument for over-polishing has collapsed.
Spending an extra week perfecting namming conventions and folder structures in a codebase where most of the code was generated is a poor use of the one thing AI cannot replicate: your judgment about what to build and whether it worked.
Your value as an engineer was always moving in this direction, but AI accelerated it. The engineer who ships, checks whether the outcome landed, and moves on to the next hard problem is worth more than the engineer who produces immaculate code that took three weeks longer than agreed.
Stop asking whether the code is beautiful. Start asking whether the outcome is what you and your stakeholder agreed on. That is the question that maps to real value, and it is the question that will matter more with every year that passes.
Ship it. Check if it works. Move on.
—
Yordan