I've been there many times. First thing you need to do is managing the anxiety of "doing it wrong" that can be paralyzing.

Errors are the most enriching part of the process and can provide valuable lessons and make you closer to your goal. So don't be afraid to start. Just do it.

Prototyping can be handy to test a few concepts before investing your time coding. invisionapp.com is my fav tool. You can even share the prototype with a group of your target audience/users to get feedback.

If you want to go deeper and learn more about how to focus on your project priorities and productivity, I strongly recommend these books:

https://www.amazon.com/Scrum-Doing-Twice-Work-Half/dp/038534...

https://www.amazon.com/Sprint-Solve-Problems-Test-Ideas/dp/1...

I wish you success on your journey!

Having personally witnessed all of these symptoms of "agile" on teams I've been on, I was pleasantly surprised to discover when I read Jeff Sutherland's book that none of these problems have much to do with Scrum, which is more of a way of thinking about building (and tearing down) processes to optimize for the things only the team can identify, than a process itself.

I think the reason these sorts of bad practices crop up so often is because internalizing and applying the sort of ego-free principles of Scrum is very very hard, even for a small team (or individual).

Reading that book [0] (particularly the first half) was eye-opening for me, and I recommend it to anyone who works in an "agile" environment.

[0] https://www.amazon.com/Scrum-Doing-Twice-Work-Half/dp/038534...

Edit: I would add that the linked article is pretty typical of things I had read online about Scrum before I read Jeff's book, and I believe are very misleading and unhelpful, as they abuse one way to solve the problems they complain about. Bad team dynamics didn't come from Scrum. Maybe Scrum failed, but that's a whole different discussion.