It is important to consider which phase you are in. It sounds like it's fairly early, and a lot of things are frequently changing, so if so, you want to optimize for agility vs stability. While you should not be in QA role long-term, if it allows you as a team to deliver things faster, I'd suggest you continue doing it.
If things are changing frequently, then investing in automated testing is not as valuable, since when the flow will change next week, there is twice as much code to change (the product code and test code).
Also, having a non-engineer do the testing allows for different perspectives to be applied to using the product. If the engineer who built a feature misunderstood it in some way, they will carry that misunderstanding to their testing.
Depending on your load, another thought is to spread the load a bit, so you are not the only person doing QA - allocate a few hours prior to release for all of you to do QA of different flows.
Engineers are likely testing the features as they develop them, but it would slow them down a lot to do full regression testing often.
When you are later on (esp. post-product-market fit), you will want to have a more sophisticated testing infrastructure, since the focus will be more on stability. At that point it will make more sense to invest in automated testing.
One thing you could try to do is to identify things that are not changing as much anymore, and outsource at least those flows, to make sure you don't have regressions there.