[embedding-shape]

On the other hand, people with that sort of experience tend to have the worst instincts when it comes to actual maintenance and long-term development of projects. They're great at starting projects, and fast too, but rarely considers the design carefully enough so you don't need a full rewrite once every year just to continue being able to add features. Slow is fast in those cases, and the people who are experts in "greenfield SaaS MVP launches" basically operate with short-term expedience traded for long-term maintainability.

Not to say they cannot learn that, but worth being aware if you're building something long-term and does hiring for that sort of project, to be upfront that the development process will likely be very different compared to what they're used to.

[diamondap]

Ha! I started my career in a company where I had to pump out custom web apps as fast as humanly possible. The apps were successful, and then I had to maintain them for several years. That's where the real learning occurred. I learned the cost of every one of my shortcuts and poor design decisions the hard way.

Many years ago, some famous developer said, "Always write your code as if the person who's going to maintain it is a violent psychopath who knows where you live." As I fixed my poor design choices one by one over endless late nights, I sometimes felt the anger of a violent psychopath toward the former, ignorant me who had stupidly plagued current me with all these problems.

When you learn the hard way, you know exactly why good design decisions are considered good. In later jobs, one of my fundamental goals for every new project was "I never want me or anyone else to have to answer a 3 a.m. call about why this system isn't working."