Don't do blue-green deploys when you have no revenue. Downtime costs you nothing and at 3,400 visitors a day you'll be lucky to drop a single request while deploying.
Pre-compute and cache to reduce your need for beefy servers.
When you can run something on your machine or in the cloud, choose your machine.
EDIT: It's less about saving money and more about not spending it.
Caching is, in general, a good thing. But it's worth thinking about how you do it. I recently sped up a large system by dropping the use of redis entirely - because it was being badly used.
During a single request there might be 50+ cache-lookups, each taking a round-trip to a remote redis server to fetch a single key at a time. Batching those up to a set/hash would have been more efficient, but the codebase had evolved in such a way as to make that difficult.
Instead of making 50+ redis fetches it turned out that just fetching all the stuff from the database was faster.
(There will be refactoring to batch up the key fetches, but for the moment there was a measurable increase in performance under current loads just by removing redis.)
Perhaps, yes. It was the latency of the network calls that was killing performance, so something local, or even redis on localhost, would have been better.
My postgres process doesn't come close to using up enough resources to push me out of even the cheap VPS tiers and I don't have to worry about locking if there's a heavy write load.
I think the point here is, SQLite setup would provide satisfactory results at this scale.
If the choice is betweeen a PAAS database offering and SQLite, you can pick SQLite. If you have skills / are prepared for managing dbserver yourself, then do that.
Pre-compute and cache to reduce your need for beefy servers.
When you can run something on your machine or in the cloud, choose your machine.
EDIT: It's less about saving money and more about not spending it.
EDIT2: Forgot to mention: use SQLite.