Bottom line: for a beginner SaaS, put originals in object storage and have a backend worker write each thumbnail as a separate object with a deterministic key; don't make edge transformation or synchronous resize-on-upload part of the first critical path.
This is the boring design, which is exactly what I want when my platform team owns the pager. It separates durable bytes from compute, lets the application ask for a known object instead of a magical transformation URL, and gives us a queue depth and a completion rate we can attach to an SLO. The important qualifier is that object storage alone is not an image CDN: if the product needs arbitrary dimensions generated at edge URLs, or permanent public image links, use a dedicated image service in front of or instead of this pattern.
How should a small SaaS choose object storage, an image CDN, or server resize on upload?
Start with the product's actual image contract. If the UI needs a fixed avatar and card size, I would store originals/{tenant}/{id} and generate thumbs/{tenant}/{id}/320x320.jpg after upload. The application can treat the second key as an ordinary artifact. Reprocessing is also intelligible: same source, same transform version, same destination key. No request-time resize fleet is required.
