It was a bunch of different tasks. For some, we did use a read only account. Other tasks (updating top 10 scores, updating the users table with their geo-ip based location etc) required write access.

Just to add some more thoughts based on other comments.. yes a lot of companies do stuff like this, particularly startups. The upside in these situations is that you end up learning things extremely quickly which wouldn't be possible in a more controlled environment. However not having backup and restore working is just ridiculous and I keep shaking my head at how they blamed the OP for this mistake. Unbelievable.

Just remember to always verify it's still read only.

Or a coworker will find the login in your scripts, repurpose it, then notice they need more rights and "fix" the account for you.

Plus read-only isn't a guarantee. You can't write data, but you can run a bad select or join that ends up effectively locking the database.

SELECT * FROM my_200_GB_table will always be there.

Why should a select or join lock a database? Surely no database lets one query starve another of IO or CPU?

I like to suffix such account names with _readonly.

"find the login in your scripts"

It's actually quite nice using a database server that doesn't require explicit credentials to be used.