Add a new feature? No. Add a column to the database? No. Add another way to lookup a data item? No. Add a new query param to the API? No. No no no no. A quick rule to follow when you want your project to keep a tight scope, to remain scalable and easy to maintain, is to say no to everything.
Feature creep can be subtle, the simple change of making an attribute required in your data model leads to a slew of other new "expected" behaviors.
- If an email address is required, shouldn't we be able to look up a user by email address? That's another index.
- Those things better also be unique. That's another check in all your update calls and probably some new error messages.
- If they are required and unique, shouldn't they be usable in all API calls in place of an ID? Every API call now gains "normalize user" boilerplate that possibly makes another internal call to the database.
- Email addresses are obviously mutable. That means they can't be included in any denormalizations down the line without expressly deciding that users might be getting stale data or taking additional measures to flush and update caches (read: big mapreduces).
- Don't forget to update all the docs.
- And the client libraries.
- And a bunch of tests.
- And their fixtures.
I want my name to be synonymous with -2 (that's code review speak for "do not submit"), every piece of feature creep I prevent makes my life a little easier, gives the project a better chance at being robust and easy to maintain. One still wants to make improvements, to provide useful features, to solve their users' problems and there are legitimate reasons to add features that will make scaling more difficult... but not many.
(TL;DR: it usually means saying yes to a better idea that you made them think they had)
When attempting to enact a default deny policy, you're going to run into two main agitators: people designing UIs that leverage your code and enterprise developers wanting to contribute.
The designers and UX people on your team or near it tend to build new features for you in their mocks. We had a joke about this back when I worked at Flock, we'd refer to features as being in the "Flickr" build since our UI guy put the mocks on Flickr. They will make something that looks pretty and cool, and is probably quite usable and useful, that shinily catches the attention of either other devs or those who feel they have some product authority. This shifts the conversation from "do we need X" to "when will we have X," pulling the rug out from under you.
Dealing with those people is usually a matter of getting at their mocks early and often to help point out which behaviors require new features and hopefully having enough design sense to help point out alternatives that they will find acceptable. Persuasiveness is pretty important in these cases as objective value can be much more difficult to show in a UI context.
As for the second type, enterprise developers, that can be a whole different can of worms. If your project is large enough to be attracting enterprise developers you are in for a swarm of features designed to match their internal structures. While they have good or important reasons for adopting those strategies internally, they almost certainly see the world through enterprise-colored glasses. It can take a decent amount of conversation to find out what it is they are really after.
In these cases your best option is to get to know how they came to their decisions internally (this can get complicated because often the corporation will be large enough that they aren't even aware of how some things came to be) and either hope that there is an easy solution to their problem that does not require their proposed changes, or work with them to come up with a less drastic change.
If you started off with a good idea that solved your problems, there's a pretty good chance that it will solve other people's problems too. If it doesn't solve anybody else's problems maybe you have the wrong problems and should start over. Adding new features to the wrong idea doesn't make the idea right, and adding features to the right idea will generally provide diminishing returns until it hits a too-many-features-to-manage inflection point.
Just because something is easy to code, doesn't mean it should be in your project. Minimize expectations, maximize stability.