I think before you start automating you business and processes you first need to know if your product will get any traction. Spending the time on making sure you have the best possible MVP is the most important thing, IMO. You may be launching a lot of tasks manually and modifying the database directly from the console at first but so be it. The fact is that creating internal tools is very expensive and only indirectly provides benefits to your product.

You'll know when you'll need to build better automation to your product; there won't be enough time to get everything done in a day.

That said, there's a downside to following this approach. When you will need to build automation tools you'll be conflicted with spending your time on automation or on improving your product. Improving your product directly provides benefits, tools indirectly provides benefits. It can be sometimes hard to convince yourself or others that you need to spend x% of your time on internal tools.

Where I work we're at a point where automation is very important. As the CTO of the company I constantly have to challenge the CEO and others that spending money on tools will give us some benefit in long term. The rule (or high level design pattern) that we are trying to implement is for every module of our product, there is a tool to understand the data better for debugging purposes (e.g. a UI to see what step in the workflow the process is in and/or what errors happened, etc), and if data is generated, there's an API/Service to get the data out easily.