I have been on both sides. Sometimes people are amazed at our project grounding up from zero so soon, and some other times people are questioning why our project progress is that slow.
It was said that compiled/strong-typed languages were faster at runtime, but slower to code. While it is true to a certain degree, it rarely matters in commercial applications.
There was also a common belief that enforcing code qualities by means of TDD/Code review/testing-in-general would increase the time to launch. Fewer people publicly speak about it since writing tests is just politically correct. It may or may not be true, depending on the effectiveness of the tests. But it still wouldn’t make a difference that matters.
In reality, development speed is tied closely to the matureness of the domain. Website development is ultra-fast nowadays, but it can be rather complicated without a rich pool of open source packages at table. “Reinvent the wheel” is a major factor contributing to the downfall of the development efficiency. When wheels are available, enjoy them. When they are not, better make sure bosses understand the development may not be as fast as he/she wants.
Building stones are important. But more important are the well-defined path of our work. Open questions are infeasible to answer efficiently. Be aware of the projects without a clear path forward. Most likely it will result in a huge amount of useless hours wasted on features never pushed to production. Whenever I can, I prefer the hardest project within the boundary of my ability over the project without an aim.