Actually, the opposite of plating would be anodizing.

I was asked to hide some existing functionality, although in my case it was because we were borrowing code from another site we owned and we were embracing simplicity.  I wasn't quite sure what to call it, and wikipedia didn't seem to be of much help, at least not in their gold-plating article.

Finding the opposite of plating was difficult, although I remembered from my freshman year college materials course that it had to exist.  Wikipedia was helpful in that case: http://en.wikipedia.org/wiki/Anodizing

And finishing.com backed me up almost verbatim:

"Anodizing is almost the opposite of plating, in that the polarities are reversed. Unfortunately, simply reversing the polarity (making the work cathodic) does not qualify you as a plater. Just as there is some degree of skill required for successful anodizing, a similar amount of skill should be expected to be a competent plater. And since there are so many different plating scenarios, you haven't even scratched the surface..."

I considered whether I could have achieved the same result by referring to shit-plating, but that doesn't seem like something one could use in an office conversation. Much like Pressed Fruit Bowl.

Title: Actually, the opposite of plating would be anodizing.

Snarky: I'm not gold plating.  The PMO wants to hide functionality they asked for without business approval.  We're calling it tin plating.

Why do you think we have so much time logged under "stabilization"?

An aspect of building software that I both love and hate is the transition from paper (spec/design) to actual working software. On the one hand there is something very satisfying about seeing actual working code.  It's thrilling to us geeks. On the other hand, one of the unfortunate side effects of the way contemporary (read: agile...-ish)  projects get managed where the software is broken down into small chunks for implementation is that it can be difficult for the developers to "see the forest through the trees".  In other words you get a lot of technically "correct" (read: works as spec'd) code that doesn't actually "work".  
 
In the enterprise, responsibility for avoiding this generally falls on the "integration testing" team, but in my experience many of the problems aren't necessarily caused by disjointed features, but a lack of understanding about how the potential customers on the site actually interact with it.

It turns out design matters.

Title: Why do you think we have so much time logged under "stabilization"?
Snarky: I didn't realize there was such a fine line between fixing bugs and gold-plating.