What approach do you use when developing a new feature?

1)do you make it work and, after it attends the business requirements, you do some refactoring to increase code quality?

Or

2)do you plan since the beggining of the development process to write the code at the stardands that you would like to follow?

I have not much experience but I'm starting to like the 1 approach. So I start writing few e2e tests that specify the main requirements. Then I start coding straight to the point, without being too much concerned with code quality. After i have a workable pull request (i. e. The initial e2e test is passing), I come back to the beggining and refactor the code, creating meaningful modules and writing unit tests for them. I feel it is easier to divide the code into modules that makes sense when you already have a messy workable version from top to down.

Other colleagues disagree with this approach. The argument is that we're often lazy and it is easy to skip the refactoring step at the end of the process. So they try to divide the code into modules since the beggining and writing the unit tests for those modules being created.

I feel that without having the new feature cleary written down on code, it is harder to break the code into smaller reusable pieces that also allows other people to easily understand it. It feels like guessing what modules will exist, but then you are always thinking " Should do A or B or C, which one is better?" instead of just going into the point.

Do you think this matter is relevant? What are your experiences regarding this?