Less Abstractions Improve Iteration Speed And Enable Quick Feature Delivery

By doing many projects I have finally come to the conclusion that it is vital to gain quicker feature delivery speed by having less abstractions.
Abstractions cause us to think about the abstraction, to support the abstraction throughout the whole application and maybe even to create a service that relies on an abstraction.
This can cause great harm to development speed and mainly new features, because we have to carry the abstraction with us through the whole process. Maybe we have to manage it, maybe we have to configure it, maybe we have to write tools for it.
Software is constantly changing. The less abstractions we carry, the faster we can change it.

It's important to think about iteration speed, would you write your software rather in a complex or easy language?
Would you want to have additional build steps?
Do you optimize for scale while not having any users?

But even then these questions are very easily solved, we want to use an easy language, we don't want additional build steps and we should maybe not optimize for the perfect millisecond request score if we can instead create more features our users love.
Now we can actually do that without sacrificing performance as much as we think we could. We can still have exceptional performance.
Golang provides us with an exceptional easy language, with very slim build processes and close to the performance of C. We can run it anywhere, it's Dockerfiles are small and minimal, it compiles quickly, it keeps build processes at a minimum compared with other languages and tools.
And it even let's us scale very well because it can accept so many concurrent requests. And once we reach that point where it doesn't, we probably had the right business idea. We probably get proper funding for the app or from the app to optimize it for these specific use-cases where it does not scale well yet.
But even then, there are many Paas that offer to host apps that scale automatically, or we would add an abstraction like Kubernetes at some point. And it makes the most sense when we'd see a need for it, because of the intense use of our app. If we have static content all we need is to have a CDN front our app and we automatically have nothing to worry about. And some like BunnyCDN are very easy to setup.

We actually don't have to worry about incremental static builds, Hot Module Reloading, large JS bundles and many other things. We don't want to carry too many build steps, too many points of bottlenecks, too many abstractions. It will hinder us on adding features and delivering them. We actually have to care about the time we invest in developing something. If we can ship a feature to production the next day, but it has a 100ms longer response time, should we not do it? Should we rather optimize and remove the 100ms and ship 10 days later? If our product is new what would add the most value to our users? Would early-adoperts of our new product with limited features prefer speed or function?

Many successful developers stick to technologies that work and that they know, where they have the greatest production development speed. I will be told: we use Java to ship our app, we use PHP or the best stack I think is PHP, MySQL and jQuery. As I just outlined I think that's a valid point, but I also think we have new technology. We should try out technology if we can, put it to the test, vet it and then also use it. Even past technology is revised, optimized and improved. It's important to stay up to date, everything is constantly changing. When you vet a technology make sure to check if it adds a layer of abstraction, check if that layer of abstraction can make your workflow harder or if it enables you a quicker iteration workflow than the next one.