In a Lean context, create a system that can evolve over time is a waste or worth in an early stage?

in projects where there's no prototype and there's only a vague idea of what the end result will look like, my team (typically) follows this path:

note: we mainly do web apps with a js client and c# rest server.

1. initialize git repos (one for web client and one for api server) with ci/cd pipelines where every commit to master will push out a build to a live staging server. devs only commit working code after they verify the new feature works locally on their machines. team leaders review the PRs to make sure everythings in order before merging to master happens. we use vertical slice architecture so merge conflicts happen extremely rarely. because one dev only ever modifies files inside one feature folder. devs are required to pull from master into their local branches as much as possible while working with their local/feature branches.
2. head dev/ architect manually tests/ tries to break the live staging app and makes sure things are heading in the right direction. if the current state of master is stable he/she pushes a tag in the format of v1.0.0 etc. another cd pipeline picks up this tag and pushes a build to the production server. the mongodb library we use enables us to do automated data migrations so production data gets automatically transformed in to the shape of the latest valid schema.
3. we don't write any automated tests until v1.0 of our production app. as soon as v1 is released we drop everything and start to write integration tests and try to achieve >90% test coverage. we do this as we feel having to write tests drains brain power that we can use to better architect the features we write. and also the requirements/app architecture changes too often until v1 where things are always in a state of flux and having to manage tests is just a waste. we however don't touch our master again until theres a good enough integration test suit.
4. once v1 is out and test suit is done, then we setup monitoring and analytics.

this is not a holly grail for us and we evaluate our processes depending on the project/task at hand. but the above has served us well so far. and the only pattern/ practise we ask every team member to follow religiously is KISS. if they submit PRs with too much complexity they'll be asked to redo that feature simplified if feasible.

IMHO and experience, I have seen that introducing those practices and methodologies at the early beginning really pays off.

It was hard to see the benefits at the early beginning, as an engineer, having as much as automated as possible really helped me deliver faster and with confidence.

Under a context of so much pressure and changing environment, having a backup as a Continuous Delivery System combined with an enough trustful automated testing suite was awesome. We were able to accept more changes and deliver with confidence that the important stuff didn't break too often.