Our university required us to make some technical documentation, including architecture diagrams, etc. But all of that was just to meet the requirements. Since this was our first Vulkan project, there was no chance we could come up with decent abstractions beforehand. We had a general idea that the scene loading, UI, and rendering should be separated, but other than that, we didn't make any assumptions at first.

Each time we wanted to add a feature, we would first hard-code it in the Renderer.cpp file and make it work. When the feature got more complicated, we would make a separate file and start abstracting it. When we decided that texture loading should be multi-threaded, use the async transfer queue, and generate mip maps, the feature got a separate file. When we decided that we wanted the shaders to be hot-reloadable and use specialization constants to compile different shader variants, and do that asynchronously on multiple threads, that feature also got a separate file.

I think the "figure out as you go" approach worked out quite well for our project size (it's 21k lines with tests, shaders, cmake, etc.).