Pardon the cheeky title, but I'll explain myself. Of course, your project is special, in that it is your work, your passion, your hobby, or possibly your nail-in-the-coffin although hopefully not.
The point I would like to make is that we should avoid thinking our project is an exceptional project, and our specific problems haven't been solved elsewhere.
Often, teams or companies are confronted with a problem and they very quickly start implementing a solution. Instead, what they should do is look if any existing solutions exist that fit their problem. And if it doesn't fit exactly, maybe an existing solution can be extended or customized.
I remember a large industrial company that had a mix of .NET, Fortran and mainframe/COBOL applications. All these applications needed to communicate with each other. History had given them a custom-built messaging framework. However, politics had actually given them two different frameworks. So they decided to build a third, that would unify all communication.
I'm not sure how it ended, it might still be under development right now. But I can't help but wonder why they didn't look at technologies like Mass Transit, NServiceBus, RabbitMQ, etc. Their excuse was that they needed to communicate with their older servers and technologies. This could easily be solved by writing specific adapters, and leaving the underlying infrastructure to a tried-and-tested product.
I've seen custom ORM's, loggers, messaging frameworks, and in one case, an attempt at a dependency injection container. All in companies whose core business is something entirely different. A colleague once worded it perfectly: "you wouldn't write your own database, would you?". Yet, the excuse is always that their project has some specific needs, that stops them from using an existing technology.
Writing a custom solution is just one part of the effort. After that comes maintenance, bugfixes, updates, change requests, etc. This amounts to a considerable cost, that business managers don't often realize at first. And I guess, certain programmers won't talk about these costs, because they want to have a cool project on their resume.
The point to remember here is that your project is special because of the business problem you're trying to solve, not because of the underlying infrastructure. Focus on that business problem, instead of the ceremony surrounding it.