How do you stop overthinking system design and start building?

Pick the smallest version that does one useful thing and build that first. When two reasonable design choices seem equally good, choose one and move on rather than trying to prove which is perfect.

Keep a backlog for the features and ideas you don't need yet. They're not lost, but they don't get to hold up the first working version.

Try doing some of the design in code. Sketch the types, function signatures or API routes you think you'll need, even if they don't work yet. The draft can expose gaps and awkward assumptions that are harder to spot while you're thinking in the abstract.

YAGNI means you aren't going to need it. As a practical rule, don't build a feature just because you can imagine needing it later. Focus on what the current version needs, then revisit the rest when there's a concrete reason.

That doesn't mean refusing to think ahead at all. It means avoiding a lot of implementation based on guesses about future requirements.

It may help to separate the problems. Are you stuck because a requirement is unclear, because you're adding too many features, or because you're trying to settle the whole design before coding? Those call for different next steps: clarify the missing requirement, cut scope, or implement a small piece to test the design.

If the sticking point is how two parts of the system communicate, look at the boundary between them. Sometimes moving a responsibility or changing that boundary makes the interaction simpler than trying to perfect the original design.