I suspect you're thinking of a product that would support a business -- the post you're responding to mentions a "subsystem". This is only a few steps beyond w

I suspect you're thinking of a product that would support a business -- the post you're responding to mentions a "subsystem". This is only a few steps beyond what anyone who completes a CS degree does at least two or three times during their coursework. If you take one of your end-of-year projects, do the work to make it actually robust enough for other people to use, and share it with the world (then do a few iterations of "wow, people aren't using this how I thought" and "wow, apparently that wasn't robust at all" and "damn I need real revision control", or even "huh; no one seems to want this at all") -- and fix the things that were wrong with your first attempts -- you're now far more valuable working any part of the process in large project dev than any of your classmates. Your project doesn't need to be big -- it probably shouldn't be, or you'll never get it out the door -- but scoping it is a lesson in itself that's really valuable to future employers. This is how I got my first software engineer job, fresh out of undergrad with a major in music; I had developed a set of music theory training drills, put them online (for free) and had already fought my way through a lot of lessons about browser incompatibilities, usability for non-technical users, how to support non-technical users effectively, etc. etc.. There was no way in hell I was ready to start a business of my own, at that point, and I was eager to work with more experienced developers -- I wanted to learn better ways to solve the problems I was struggling with -- so in seeking a job I wasn't just someone saying "I learned some stuff in school; can you pay me money for it?". I was saying "I already know somewhat what you do here; I want to learn how to do it really well, with you -- will you pay me to do that?"