hahhaha
achei muito top este post porque, sendo coincidência ou não 😏, defendi o "feito é melhor que o perfeito" em pelo menos uns 3 dos 5 posts que tenho aqui. 😅

É bem interessante sua visão e a conclusão, e para contribuir, acrescento a contextualização.

que realmente, em hipóteses como as apresentadas, está seria uma frase utilizada para mascarar um trabalho ruim, preguiça etc.

no caminho em que apresento e que trilhei, que é o empreendedorismo, existem outras questões, que fazem até mesmo referências do meio defenderem essa linha de pensamento.

Então, não precisamos olhar superficialmente o cenário em que um mero código está feito, embora não perfeito, e é assim que ficará para sempre e segue para a próxima gambiarra. kkk

Existirá casos em que teremos questões muito mais importantes que a beleza de um código.

Por exemplo, no lançamento de um MVP, para validação de uma ideia. Em que validar a demanda por determinado produto/serviço e mapear indicadores importantes, como custo de aquisição de clientes (cac) são mais importante que o código, tecnologia stacks etc. Tanto que, muitos empreendedores estão dando os primeiros passos sem nem ter códigos, recorrendo a estas plataformas no-code ou misturando diversões serviços para entregar a essência do que foi planejado.
Importante a ser considerado, é que isso não é um pacto de que sempre será assim.

Depois que temos a demanda pelo que fizemos validada, cac mapeado e até mesmo uma receita recorrente dos primeiros cientes, ficamos muito mais seguros de, em uma segunda fase, investir tempo e recursos na qualidade do software que serve de base para o produto/serviço que estamos oferecendo.

Empreendedores reconhecidos afirmam "se seu negócio começou perfeito, começou tarde"

No livro Startup, Modelo de negócio o autor defende que o MVP, depois de validado, pode ser "jogado fora" (não diz que deve ser, mas que se tiver que jogar fora, tendo retrabalho, está tudo bem). Que depois de experimentações e validações, o produto ideal pode ser algo totalmente diferente do que foi idealizado no começo. E como falei, em uma próxima fase, se tem tempo e recursos para investir em um produto melhor.

Nesta próxima fase, já não caberá um DEV contratado chegar e querer dizer que o código dele está feito, embora imperfeito e que isso já basta. Não será oportuno este posicionamento neste novo contexto.

E me cito como exemplo:

1. Quando precisava tirar a ideia do papel, conquistar meus assinantes, mapear os requisitos para o software se diferenciar etc., a qualidade do código era o que menos faria diferença.
2. Hoje, se for refatorar o código, posso recorrer a um DEV mais experiente que eu e exigir dele o melhor código possível. E não aceitaria dele a frase em que levo para vida.

👊😉