3 ms·
> Your goal, when launching a product, is to build a product that solves a problem for your users. This is the main takeaway, in my opinion. I've been at small
by twodave 6y ago
> Your goal, when launching a product, is to build a product that solves a problem for your users.
This is the main takeaway, in my opinion. I've been at small companies who were under-architected "because we can" and large companies who were over-architected because someone in the leadership chain was enamored with a particular technical choice.
In the end it's a cost curve and depends heavily on the nature of your business. I can say personally if the business is even mildly complex (not necessarily large, this could mean a web app + a mobile app + a single RDBMS) I'd sleep better having some AWS (or other cloud) alerts set up to monitor uptime/etc. Others have mentioned CI/CD, but again, heavily depends on your needs. I worked at one place that survived uploading .zip files to Elastic Beanstalk for _years_ to update our PHP website.
For some of the other data compliance/up-time/service availability stuff, I'd expect to have the revenue to cover the sort of overhead that introduces (otherwise you're just not charging enough, or the business isn't really as viable as you think).