I've wrriten a whole lot of framework code. I've written a variety of factory objects, component base classes and even an Object Relational Mapper. And if I was doing it all again, I wouldn't write any of them.

My use of factory objects has dropped precipitously now that I'm using dependency injection (I tend to prefer Spring.NET, I know Castle partisans and I keep meaning to have a look at StructureMap). These existing DI frameworks provide a large amount of functionality and I didn't have to write it.

I few years back I wrote my own system for doing ORM. It tracked the state of objects and could tell if they were unloaded, clean, or dirty. It could automatically determine the correct order to persist objects based on their dependencies. It worked fairly well, and there are a few systems still using it in production. It does have a few drawbacks though. All business objects must derive from a specific base class, implement a whole lot of framework code to update the state and determine the dependencies and the database interaction was all manually-written stored procedures. These days I'd use NHibernate, which has all the advantages listed above (and many more) and none of the disadvantages.

The point is that regardless of how revolutionary you think your application may be, most of it really isn't that special. It's worth finding out if someone else has done what you need already. This is commonly known as "Build vs. Buy". Developers instinctively choose "Build". The point of experience is to know when "Buy" (or download free nifty open source package) is the better option.