Here’s one that sounds like it ought to be simple, but when it isn’t it can bite you: Plan for how you’re going to test your app.
Does your app depend on sending data to or receiving data from other systems? Does your app validate the data it receives and handle failures gracefully? User entered data should always but always be treated with the utmost suspicion. But even generated data can bite you if the other end makes an apparently minor change to a database schema.
Or what if your app is displaying (for example) catalog data provided by a third party that has to be filtered based on user roles. And, for example, let’s say that this data is being updated on a very regular basis. How do you very that users are seeing all of the items they are supposed to see but none of the items that they aren’t supposed to see?
The standard method is to set up a set environment and populate it with real data so that you can test there. Which works until you have enough moving pieces and enough players and third parties who don’t want to play. You have to get creative and you have to code with more even paranoia than usual. The trick is to not leave it to the end. Prioritize it, think about it, document it, and get everyone involved to sign off on it. And have a fall back plan, because no matter how much testing you do, you can still get surprised.
Sam Herdman 