The articles that are most relevant are probably ones from YC itself, along with ancillary material on startup woes, pitfalls, etc. Among the advice is how to validate ideas, is how to maintain momentum, knowing when to ship, when to wringing your hands and stop adding features, etc. Obviously geared towards startups and businesses but also applicable to projects.

The pieces of advice that I try and follow (and often fail at following) are:

* Commit to completing projects, not time. I'm bad at estimating time and putting time limits stresses me out. I prefer to work towards a goal rather than a time limit.

* Be vicious about removing features that are superfluous to the main project in order for it to ship. "Nice to have" features can be added later. A mediocre project that ships and can be improved later is better than a perfect project that never ships.

* Get some space. Getting a little burnt out is easy to do and almost inevitable. Even taking a day or week away sometimes recharges my batteries. The hopelessness I feel about the amount of effort required to complete seems less daunting once I've recharged. This is even better if it ships because the daunting extra "nice to have" features, refactoring or complete architecture overhaul seem less daunting when I'm rested and recharged.

* Don't get into "all or nothing" elements. Break up large projects into smaller manageable pieces as much as possible. Insofar as is possible, have smaller "shippable" elements that contribute to the larger project so that progress is apparent and, in the tragic event that the big project doesn't ship, there are smaller gains that have been done in its wake. Large projects also tend to shift during development so having smaller "wins" helps both with morale and provides tools to help shift course more easily.

* Don't be daunted by work. Rewriting parts of the architecture or even the whole thing might seem depressing but its a lot easier the second time around as the first attempt is exploring the ideas. A project with a clear specification is a lot easier to write than one where the specification is being written through trial and error. Elements of the project can also be used to accelerate the re-architecture/rewrite. Pixar famously scrapped many of their movies because they didn't work, only to rewrite it to be much better but they were able to re-use a lot of work and get back to the same point much faster the second time around. If what's had can be shipped, ship it, but in the case that it does need a rewrite, this often seems much more daunting than it is.

* Isolate complexity. Sometimes architectural elements need to be ugly for a variety of reasons (lack of knowledge about the domain, experimentation, exploration, effeciency, etc.). Beatiful code and proper abstraction is its own form of optimization and one should not prematurely optimize. Instead, give up the idea of writing beautiful code and let the code be ugly. The interface must be clean (or API, or resulting data) so that it can compose with the rest of the system and so that the ugliness doesn't infect other parts of the archicture, but the element itself need not be pretty.

* Make 'todo' lists. A minor hack but one that helps me a lot. There are different todo lists for different scopes. One big todo list for long reaching broad and underspecified goals ("epics" in agile language?) and smaller todo lists for day-to-day elements (fixing bugs, making functions, developing UI elements, etc.). The day-to-day todo also helps with morale as tangible progress can be seen as the items on the list get crossed off each day (I think PG is the original person I heard this from).

Completing projects is hard work. There's no real hack that will get you through it. To make sure you're in a position to do hard work, make sure the basics of the Maslow hierarchy are taken care of (food, sleep, cleanliness, shelter, money, social relationships, etc.).

The above list are what helps me complete projects but the overall one is that I'm of the mentality that it's a slog and that I should be prepared for it.

[0] https://youtu.be/CBYhVcO4WgI?si=5iMC6crzmPM3xfGe