I'll throw in that this doesn't necessarily mean just use Ruby on Rails and get coding.
I mean, that will probably allow you to ship a bare bones MVP pretty quickly, but making improvements to said MVP in a timely manner may be a different story.
Case in point: I used to work for a company that developed a product that was made in RoR and was probably actually pretty nice looking at one point. Unfortunately customers had ideas for what sort of improvements should be made to the MVP, and very few suggestions were turned down. So, after some time, the codebase grew pretty hellish, and it became harder to release substantial improvements in a reasonably timely manner. If I remember correctly shortly before I left they decided to replace it with something built from scratch using a leaner Ruby framework called Sinatra.
For that reason I'll typically write projects in Node or Golang, but typically Node. They're flexible, they're not a framework, they're not opinionated, but at the same time they both still have robust package ecosystems so I don't have to reinvent the wheel.
And actually, by all means use new technology if you can honestly tell yourself and your customers that it allows you to ship faster. Just remember, you writing code faster != you being able to ship faster. You'll probably have to bring on additional employees, so your choice of tech has to factor in how quickly you can hire and train someone to use your tech stack as well as how well they can reasonably perform with it. That being said, developers who like using your uncommon technology or tech stack are typically going to be a little more enthusiastic, just don't go too far.
> Case in point: I used to work for a company that developed a product that was made in RoR and was probably actually pretty nice looking at one point. Unfortunately customers had ideas for what sort of improvements should be made to the MVP, and very few suggestions were turned down. So, after some time, the codebase grew pretty hellish, and it became harder to release substantial improvements in a reasonably timely manner.
This is the problem, not Rails. I've been using Rails for years since 2009 without any problems. I've also used PHP, Java, and Node. These projects have survived 5+ years not because of any language or framework but by treating code as a craft.
Ultimately you're in business to convince customers to pay you money in order to use the thing you built. If the code base goes to hell after making customer-requested improvements to the MVP then that's a problem with the design of the MVP code base combined with a lack of refactoring to improve said design. It could be that management didn't want to spend the time or money to rebuild the codebase to let those new features be added in an organized way; that's a management problem. A very experienced developer/lead could translate from nerd to English and from English to Management so the people in charge could understand why they needed to not get new features for three months while the code gets refurbished. If management still says no, because there's no money or they've got impatient customers then that's a different issue.
The specific part of "code as craft" that you need here is a recognition of the value of what chefs call "mise en place". You need to have your work environment in an orderly state that it enables you to work efficiently.
I mean, that will probably allow you to ship a bare bones MVP pretty quickly, but making improvements to said MVP in a timely manner may be a different story.
Case in point: I used to work for a company that developed a product that was made in RoR and was probably actually pretty nice looking at one point. Unfortunately customers had ideas for what sort of improvements should be made to the MVP, and very few suggestions were turned down. So, after some time, the codebase grew pretty hellish, and it became harder to release substantial improvements in a reasonably timely manner. If I remember correctly shortly before I left they decided to replace it with something built from scratch using a leaner Ruby framework called Sinatra.
For that reason I'll typically write projects in Node or Golang, but typically Node. They're flexible, they're not a framework, they're not opinionated, but at the same time they both still have robust package ecosystems so I don't have to reinvent the wheel.
And actually, by all means use new technology if you can honestly tell yourself and your customers that it allows you to ship faster. Just remember, you writing code faster != you being able to ship faster. You'll probably have to bring on additional employees, so your choice of tech has to factor in how quickly you can hire and train someone to use your tech stack as well as how well they can reasonably perform with it. That being said, developers who like using your uncommon technology or tech stack are typically going to be a little more enthusiastic, just don't go too far.