What I've found to help for small projects is to start with a very lightweight use case analysis. For instance:
* A small vision document: This project is a (short description) targeted at (accountants / small business / boy scouts). It solves this problem that the target market has: (pain point). Its main features are (what makes it a good solution / what differentiates it from the alternatives).
* Main use cases: Some Trello cards with the main user-facing features, described at a very high level.
* Technical overview: You seem to have that covered. E.g. it will be a web/mobile/desktop/command-line app built on (language/stack) with this architecture (microservices, MVC web app, client/server, etc.) storing data on (S3/SQL database/flat files).
For a 1-person small project, don't overdo this part. Once you have this high-level overview of the project, try to implement the bare minimum necessary for the "happy path" of the main use case (i.e. without worrying about exceptional cases yet). Mock other aspects as necessary (e.g. authentication, dependent data sets, complex business logic, etc.)
This will leave you with a huge technical debt that you'll need to crawl out of as move forward, but it will avoid analysis paralysis and over-architecting.
For a more structured approach, one source that I recommend is "Use Case Driven Object Modeling with UML" (http://www.softwarereality.com/UseCaseDriven.jsp). It shows a technique to bridge the gap from the business requirements to the technical design and implementation.