Random Thoughts on Software Engineering

Do Not Build Foundations

ready-foundation

It is an unwritten rule that when you start a project, every decision to acomplish something quick and dirty will be part of the codebase for years to come. From another perspective - most of the tasks at the beggining of a typical software project don't have much added value from a business perspective, while holding the biggest risk fir long-lasting technical debt or security issues.
There are, of course, exceptions. One of the more notable ones are when a specialized software architecture is in place, due to, say, pursuing a specific architectural requirements. In that case the architect should create a seed project with all key concepts that should be followed and modules in code already before the most senior developers being onboarded by the architect personally. Also the architect should periodically check on the team that the design or specific concepts are really followed.
In most cases, when there are no strong opinianated choices on the topic of non functional requirements - the strong opinions on these matters usually arise in production, eclipsing the focus on functiinalities - you should start with a seed project.
There us a plethora of seed/template/archetype/boilerplate, etc. projects, depending on the technology you use and context you operate in.

selecting-foundation

There are also many more websites that provide collections of ready components:

These are not an exhaustive lists by any means but serve as an example what can be found with a little digging.

Pick a trusted component source and reuse it across codebases.
Make sure all engineers use the same source of components, before using AI to generate them and you will accelerate development, while keeping your team's focus where it matters.