
It costs Slashdot money to run these servers. Are you a thief to access their web pages?
It costs Google money to host Gmail, or perform your searches. Is Firefox enabling theft because it makes Google searches easy?
Of course not. The argument seems to be that popularity, i.e., heavy use in the way it was intended to use, means that the service was being abused, is specious.
Hopefully, your team is a profit center, and not a cost center. If your team is generating the profit, then the people who make the products are Kings. All stars. You should have the goal of making the finest systems possible -- under your constraints of time and budget.
Expect the developers to keep learning; "We don't have expertise in that," should be replaced with, "we should explore XYZ".
Plan on three versions of any important system: Force them to develop prototypes; demand basic functionality within a month of starting. Then revise and replace that prototype with another, better prototype. Then plan on a final version (The Third System) that discards the stuff you didn't need.
Work to avoid heavy-weight programming. I was once hired at $240/hour to write code for a company that had a large team of developers already. I knew only slightly more about the domain than they did. Their problem: this company had allowed the developers to just examine everything to death. They hired me to help because I could actually deliver within rough deadlines.
I disagree with the concept of hiring junior programmers, unless they're just apprentices. Do you want to hire a junior surgeon to do your operation? Or hire a junior Engineer to build the bridge your wife drives? No: senior people do important work. Junior people learn how, and do less critical, separate projects.
Good, adult programmer/engineers don't need much managing, but you need them to make the product. They do need somebody to help them see the bigger picture -- but any team of two engineers can do that for each other in turn. So you're really there to service them.
Fire the jerks. Develop some standard of productivity -- even if it's lines of code + group source code reviews -- and fire the people who are clearly not fitting in.
A bug in the code is worth two in the documentation.