There is a particular kind of excitement that only exists at the beginning of a software project.
You have an idea.
The repository is empty.
The possibilities are unlimited.
You choose the stack, create the first component, design the landing page, connect the API, and suddenly the project feels alive.
Then comes the difficult part: finishing.
I have started enough projects to recognize the pattern.
The dopamine of a new repository
Starting a project gives immediate evidence of movement.
A new folder exists.
A GitHub repository exists.
A first commit exists.
A dashboard appears.
But these are weak signals.
The stronger signal is whether the system survives the boring middle.
That is where requirements become annoying, edge cases multiply, and the final ten percent refuses to cooperate.
My project list became a mirror
Looking across my projects, I could see different levels of completion.
Some were close to shipping.
Some were prototypes.
Some were experiments.
Some were ideas that taught me something and then stopped.
There is nothing wrong with experiments.
The problem is when every project is treated like it must become a product and every new idea is allowed to interrupt the old one.
That creates a graveyard of almost-finished work.
The last 10% is where the engineering lives
The first 90% of a project often contains visible progress.
The last 10% contains:
- permissions
- validation
- error handling
- deployment
- testing
- exports
- accessibility
- documentation
- edge cases
- cleanup
It is less exciting because none of it produces a flashy screenshot.
But users experience that last 10% constantly.
I started changing the definition of done
Before, “done” often meant the feature worked on my machine.
Now I want “done” to mean:
- the happy path works
- failure paths are understandable
- the feature is connected to the rest of the workflow
- permissions are correct
- deployment works
- important edge cases are tested
- I can explain the implementation
That definition is harder.
That is the point.
Why I still want to build ambitious things
The answer is not to stop experimenting.
Curiosity is one of my strengths.
I want to build AI assistants. Financial tools. Developer tools. Systems that connect hardware and software. Applications that solve real operational problems.
The goal is not to become less ambitious.
The goal is to become more disciplined about ambition.
My new constraint
I want fewer active projects at the same time.
Before opening a new project, I want to ask:
- What am I trying to learn?
- What does success look like?
- What is the smallest shippable version?
- What existing project am I neglecting by starting this?
If I cannot answer those questions, the idea probably belongs in a notes file instead of a repository.
Learning to close loops
This lesson extends beyond coding.
Unfinished work creates mental debt.
Every half-built application occupies a tiny part of attention.
Every unresolved bug sits in the back of the mind.
Finishing creates closure.
And closure creates capacity for better ideas.
The lesson
I still love starting projects.
I probably always will.
But I no longer want to confuse starting with building.
Building means staying when the project stops being exciting.
Building means debugging the ugly part.
Building means finishing the integration.
Building means testing the thing you thought was already working.
Building means shipping.
The next stage of my growth is not learning how to start faster.
It is learning how to finish with the same energy I bring to the beginning.