Surely that would have taken you ten minutes at most? I can't imagine anything more trivial. I can't imagine that the client wanted multiple survey results from the same person either.
Any feature which fundamentally transforms the final result, say by blocking a transaction, will be one of those cascading features. Sure just adding a "good enough to be 80% there" could be simple. Yet what happens when the client turns around and says "You delivered a broken app to me, I tried submitting my survey 3 times and only the first time was it accepted".
Sure this feature can be accommodated. The client might ask for special handling of test email accounts. Or an admin panel. Or a report & moderate workflow where they can override the block.
Getting to the core issue: the client did not see the value in the proposed work. If you are getting paid and spending extra time unpaid to give value to clients, you better be doing so because the client is going to be thankful.
Imagine a scenario where the OP ignored the clients wishes, implemented the feature anyway, tanked the negatives, all so that the client would not lose money to fraud, and thus prevent the client from seeing why the feature was needed in the first place. Lots of work, negative reward for the programmer.
The Op sounds like they were trying to graft more money from the client to me. The email was already stored. A trivial check would have reduced the triviality of the exploitation.
Not to mention that multiple survey results from the same person cannot be assumed to be what the client wanted.
Also, while keeping track of email addresses is simple, making such a system hard to exploit isn't all that trivial, with there being wildcard and throwaway email addresses and so on.
This to me would be a fundamental feature of the system - multiple survey results from the same person are of no value.
But I want to echo that your comment is accurate, maybe not 10 minutes, but it’s a rounding mistake worth of time on it’s own. The results got emailed as soon as POST so we didn’t keep a db along side the app. Keeping the list of used emails would have been easy but it would mean keeping a log/db/redis/flat file somewhere. That ends up eating a little more time.
I think what we have illustrated here is exactly what happens in the bigger hacks. “Why didn’t they just... it takes 20 minutes to do that” and yes it does but it was packaged probably with other things that got killed.
If you say, "hey, for the cost of a gift card or two we can prevent a single person from disrupting our campaign" it's much more likely to get approval.
And agree, this should be extremely trivial to implement and if the project was quoted prior to development should be included in the initial scope.
We can't prevent all malicious behavior but we can prevent the easy stuff.