The comfort of not working with real data

I am very fortunate to have been working on many projects that started from scratch, so I never had to deal with pre-existing databases and structures.
Although this fact makes it easier to create a good architecture, you'll find yourself constantly inserting some bogus data into the database to be able to test the application.
And usually you'll wipe your database clean once you're ready for release and forget all about that data.

Don't do that. It won't cost you a thing to export the test data to a SQL and have it handy in case you're ever going back to the application to change something.

Let's say your app was performing great and you now have 2000 users using it. Going back brings forth some problems:

• User data is subject to privacy laws and cannot be handled freely.
• Working on the real database is always stupid (remember when you didn't include a WHERE clause to a update statement?)
• Washing real user data clean of all private information is sometimes quite difficult.
• Huge amounts of data make detecting errors more difficult.

Privacy laws may be the most important point in the above list I think. If you're working on the real dataset you're in trouble once you want to outsource the development or bring in new people to the team. They'll have to sign a NDA and even under a NDA they could make the mistake of disclosing this information without their knowledge (most NDAs don't pass on liability in such cases, in that case you're now facing two legal problems. Sue your programmer and get sued by privacy advocates).

Not taking such risks is usually the better choice! By using your bogus development database you'll be easily able to verify behavior while having the luxury of being able to freely bring in new members to the team (mind your IP).