Table of Contents
Introduction
What Does It Mean to "Seal" a Project?
The Release Checklist
README
The "About" Section
Branch Hygien...
For further actions, you may consider blocking this person and/or reporting abuse
Honestly, if you came over to my house, you’d probably get the bonfire version of that (marshmallows included). Which is also why I try to keep my projects a little less… that.
Stuff like Release Please for versioning, tests running in GHA from the start, and code scanning turned on just keeps things from drifting into chaos. For most projects,
mainis plenty, and once something’s merged as a feature, the branch name matters a lot less than the outcome.Really liked your list—it’s a solid reminder of all the things that are easy to put off as “I’ll get to it later” but never actually finish. Also, throw in Dependabot after v1 ships—it's magical for upkeep!
Sometimes I'm guilty of a bit of mess too, but my overly organized self never lets things stay that way for long. And nobody really ever comes over anyway 😄, if you're the same, you're doing just fine 😄
As for branches, yes, sticking to just the main branch can be enough in simple scenarios. But I usually create separate branches so that if I make a change that completely breaks everything, I can always fall back to
main, which holds a stable version of the application, and compare the two if needed.That's great checklist! My personal githum projects are rather small and prepared for demos (at least SO FAR 🤫). So readme is must-have for me, but now I see I must pay more attention to other detals, like versioning. Thanks for this article, Giorgi! (BTW I'm back in cold Poland 🙃)
Thank you! Every now and then, I like to do a bit of repository grooming and refinement just to make sure everything stays clean and well-organized. You can do the same, it's a medium difficulty effort, but it really pays off and gives you that satisfying sense of pride.
By the way, I've never been to Poland, but from what I've seen, it looks like a beautiful country, especially for someone like me who enjoys colder weather. Italy might still be my favorite, but Poland definitely holds its own.😄🇵🇱❄️
Poland is beautiful 😄 the nature actually reminds me a bit of Georgia!
There are also lots of great cities with lovely old towns, so honestly, if you don’t mind the lack of tropical vibes, it’s absolutely worth visiting 😊
I'm not a "tropical vibes" guy, far from it 😄So it's good enough!
Great article! When I was finishing my project, I realized I was completely burned out, tired, there were no stars, views were falling, basically, I had no motivation to continue, and even more so, the quality of the code was complete garbage! In the end, I gave up. But I finished. At least MVP. And yet, looking at the project, I still felt a strange feeling of failure and victory. The victory was that I was able to finish it. In the end, I decided to start from scratch and rework it. And you know, I'm not as eager as I used to be, but now the pleasure comes not from the product's functionality, but from the cleanliness of its code, good architecture, and all that! Let's see if I can create something worthwhile?👻
Thank you!
Every detail matters staring from code cleanness all the way to how it's packaged, wrapped up and delivered. Sometimes it can be hard to find that final energy to go run that final stretch in a quality manner, but, you know, we gotta do what we gotta do - we're professionals.
This is the part nobody talks about and exactly why most projects stay as cool demos instead of actually usable tools.
The final 1% (README, examples, badges, license) feels like paperwork. But you're right it's the difference between someone cloning your project and someone using your project.
I've definitely been guilty of shipping and stopping. The examples part especially I've wasted hours figuring out basic usage on projects with no examples.
What's your timing on the final 1%? Right after coding, or do you come back fresh?
Bookmarking this. 🙌
Thanks for the great feedback.
As for your question, I generally do that 1% just after I'm done with the functional part - the source code. But I like doing it when I'm fresh, so if I have time, I leave it for the next day, because that "1%" sounds like it's easy and simple, but it's far from that.
The branch hygiene and release tag sections are underrated. I'd add one more to the checklist: a
CONTRIBUTING.mdfile with clear setup instructions. The number of open-source projects that lose potential contributors because there's no documented way to run the project locally is staggering. Also worth noting — GitHub Actions now lets you automate most of this checklist. A workflow that enforces branch rulesets, auto-generates changelogs from conventional commits, and creates release tags on merge to main turns this from a manual checklist into a one-time setup.Nice pointer!
contributing.mddoes help the overall visibility and ultimately helping coding agents.Thanks for sharing! The checklist is really valuable, and I also really appreciate the motivation it gives to actually finish a project properly. Sometimes it’s hard to find that push, and this post definitely helps with that 🙂
Thanks for the great feedback, I really appreciate that! And yes, finding the energy for that last stretch can feel impossible sometimes, but, at the end of the day, it's those tiny details that make a huge difference, so it's always worth going the extra mile.
I love the idea of the “final 1%”, because that’s exactly where most projects quietly fall apart. The code works, but everything around it (docs, versioning, releases) is what actually makes it usable for other people… and for your future self.
Thanks for the feedback!
This is a highly practical and well-structured guide that highlights a commonly ignored phase of development. The emphasis on documentation, versioning, and CI/CD health makes it especially valuable for real-world deployment readiness. The checklist format is clear and actionable, helping developers build discipline. A great reminder that shipping code isn’t enough maintainability, clarity, and reliability truly define a finished project.
Thanks for such a great feedback!
The last 1% is where I spent the most time on my side project. Six months of coding, and the final polish (i18n in 6 languages, edge cases, accessibility) took almost as long as building the core features. You think you're 90% done but that remaining 10% is really another 90%.
When a project is big enough, documenting it can definitely take just as long as creating it. That might sound like taking too much time, but well-documented software saves much more time than we can imagine.
Thanks for that perspective!
The final 1% is always what separates a repo people star from a repo people actually use. I'd add one more item to the checklist: a CONTRIBUTING.md with a clear 'how to run locally in 3 commands' section. I've abandoned so many promising open-source tools because the setup was a mystery. Also, GitHub Actions for auto-labeling stale issues and PRs is basically free maintenance automation that keeps the project looking alive even during quiet periods.
Information about how to contribute is definitely one of the most important parts of any software, especially open source. It can live in the README, but separating it into its own file is also a best practice. Great point! Thank you!
This is so true.
That last 1% always feels like “I’m basically done”
but in reality it’s:
– README
– cleanup
– making it usable for someone who didn’t build it
And somehow it takes more mental effort than the actual coding 😅
Great reminder that “working” ≠ “ready”
So true! And that 1% makes everything so much better!
This is a really helpful article. I think all devs need to follow this checklist, atleast if they want it to be of a real impact. I agree that github repos could be really confusing considering just how complex the website would look like for a non-dev.
I guess the least a dev can do would be keeping a well structured ReadMe file or an about section in their repository.
After reading this article, the picture is clear, a ReadMe file is the bare minimum and ruleset discipline must be maintained. Before this, I just used to generate from an available LLM, a well structured ReadMe or even for the project title 😅.
Thanks! I used to not pay attention to this detail in the past, but the experience showed me, it's not the right way.
I'm glad you've found it helpful!
This was actually a very timely article. I was at the final hurdle of releasing my second Open Source Repo. I reviewed everything in this article and turned it into a SKILL for my Agent. It covers things I knew nothing about, like rulesets.. Thanks @georgekobaidze! My repo is now published following the guidance here, and I made my first post here on dev.to talking about it!
Oh wow, I'm honored to have indirectly contributed to your work, this is fantastic to hear. Thanks so much for letting me know, and best of luck!
Looking forward to your README article. That's one of my favorite things to do!
I’ll try to write it as soon as I can! Thank you!
There is some great advice in this post, that I have taken to heart and will follow in future releases. Sometimes its difficult, after spending months and months talking to a computer, to remember how important it is to effectively communicate with the end user; a human.
I have found that the Rubber Duck method not only works for getting past coding issues, but is also helpful when creating documentation so that it naturally gets oriented towards users that haven't spent the last n months of their lives up to their elbows in the code.
Once again, great post thanks for sharing.
Thank you! What I usually do is avoid rushing to publish a repository right after I finish coding. If possible, I leave the "final 1%" the sealing part for the next morning, when I'm fresh and full of energy. That way, the project not only works well, but also looks polished to the outside world.
The Rubber Duck method sounds interesting in this process, I haven't tried it yet, worth trying! 🦆
Very important post. Perfect timing 😀
Thanks! I'm glad you've found it useful.
Very interesting!
I made a post today about my milestone (1000 github stars for my project).
dev.to/debba/from-0-to-1000-github...
Thanks! And well done, keep it up!
great article buddy, this is just what i need at the moment, keep it up, cheers!
Thanks a lot, glad it helped!
Thanks, this is exactly what I need now...
I think you saved me tons of work.
That's fantastic. It's always good to hear that someone has found my work useful, thank you!
Dude. This is beautiful. Bookmarking for permanent reference.
Thanks a lot, I appreciate that!
Thank you , very informative
I appreciate that!
It’s funny how the first 99% takes 99% of the time, and the last 1% also takes 99% of the time. That final README polish and CI fix always humbles me.
That’s kind of a paradox.
Great stuff, solid!
Thanks a lot!
Great Article.
Thank you!
Nice!
Thanks!
Thank you for releasing this article (especially the part about tagging), around the submission deadline for the #4118 challenge.
It helped me.
I’m so glad it helped you! And good luck with the challenge!
Great article! Thank you
Thanks a lot!
Thank you for this great checklist to consider, most of the time I just want to get over with the project and skip some of the steps, which should not be skipped.
You're welcome!
We're all guilty of skipping those steps at some point, don't feel bad about that 😄
Thank you!
You're welcome!