Pensando principalmente em back-end, que acredito ter mais opções diferentes.
O que usaria pro banco de dados? Algum ORM?
Que linguagem?
Explique suas razões.
Acho que vai gerar uma discussão legal. :)
Eu entendo que quando se está fazendo um MVP, onde a idéia é tirar do papel para o mercado o mais rápido possível, qualquer stack que você já domina quase sempre é o caminho mais otimizado. Entretanto, tem algumas tecnologias que de fato deixam o processo menos dolorido.
Aqui eu vou assumir que o MVP em questão é uma aplicação web, já que estamos falando de stacks.
Go é uma linguagem espartana - simples e direta - bastante poderosa. Em performance é comparável com Java e outras linguagens com GC que já estão consolidadas no mercado faz bastante tempo, mas estou divagando, performance raramente é importante em MVPs.
A maior vantagem do Go é que ele compila - e muito rápido - diretamente para um binário pronto para ser executado pela máquina alvo (UNIX, Linux, e Windows). Esse binário é independente de depêndencias externas, como ter uma runtime ou bibliotecas que é o caso de Java e NodeJS, isso simplifica bastante o setup dos servidores, ele precisa somente executar o binário gerado pelo compilador e sua aplicação já está estará funcionando.
Também já vem incluido uma biblioteca nativa para lidar com arquivos de de templates HTML, isso possibilita gerar páginas renderizadas no servidor, algo parecido com o que o PHP, JSP no Java e Razor no .net fazem, se usar um framework javascript para renderizar sua aplicação não for uma necessidade para seu MVP, pode ser uma boa opção.
Aqui temos várias opções, a primeira e mais óbvia são bancos relacionais tradicionais (postgres, mysql, etc.) e sendo bem honesto acho que qualquer um serve. Ja não é pratica tão comum aplicações novas aplicações usarem stored function/procedures e manterem lógica de negócio dentro de objetos no banco de dados, o que faria ser necessário casar com algum vendor específico, e se o MVP em questão não depende de uma base de dados legada, usa o que for mais barato no seu cloud provider de escolha.
E falando em preço, um banco relacional provávelmente é opção mais cara, já que é basicamente um servidor que vai ficar ligado 24/7, não escala sozinho e quando escala geralmente é pra cima.
Tirando a questão de custos, os bancos relacionais tem um ótima experiência para os desenvolvedores, toda linguagem praticamenet vai ter uma biblioteca ORM (GORM, no go, por exemplo) e há praticas consolidadas para gerenciamento dos schemas como migrations e caracteristicas que ACID que garante que as transações são executadas e com consistência imediata.
Se você não está disposto a fazer o investimento em um banco relacional, há opções como DynamoDB da AWS que você é cobrado só pelas requisições realizadas e não pelo servidor do banco de dados. A disvantagem desse tipo de solução é a mesma de qualquer banco NoSQL, consistência eventual e por schemaless é mais difícil garantir a consistência dos dados. A AWS provê um SDK para as principais linguagens de programação, go é uma delas.
Meh, a ultima vez que trabalhei com frontend foi na época do AngularJS 1.5 que agora já está praticamente morto e enterrado. Então o que vou escrever aqui tem mais a ver com minhas limitações ao desenvolver aplicações para o browser.
Acho os frameworks populares do mercado como React, Angular e Vue ótimos, mas com uma curva de aprendizado muito grande que atrapalharia ao tentar executar um MVP (no meu caso).
Optaria por um framework mais enxuto como o Svelte cominado com framework de CSS como tailwind, qualquer coisa que me deixe mais produtivo do que escrever JS e CSS vanilla.
Tem um video interessante do ótimo canal Fireship no YouTube onde ele implementa a mesma aplicação em 10 frameworks diferentes para referência:
Particularmente, sou muito adepto do .NET. Tenho um bias porque comecei na programação "de verdade" com C#, então o .NET foi um pulo muito fácil de ser feito, mas em comparação com Java (não conheço muito do Spring, então não posso opinar muito) eu acho .NET muito mais simples de se trabalhar e em comparação com o JavaScript eu acho mais sólido, apesar de saber que em testes de performance um background Node.JS geralmente tem um desempenho melhor.
Eu já desenvolvi em várias versões do .NET, começando com .NET Core 2.2 e hoje pulando para o .NET 7, então acompanhei muito o crescimento e evolução da plataforma. Muita coisa ficou mais fácil de ser feita e hoje existe a tecnologia de Minimal API que torna extremamente simples fazer uma API para MVP
Banco de dados eu já não tenho tanto uma opinião porque dependeria do quão avançado seria o MVP. Se for algo mais simples, nem usaria banco de dados, começaria só com arquivo txt mesmo. Agora se for necessário algo mais sólido, que utilize principalmente de pesquisa, consulta ou relatórios, aí eu partiria para um MongoDB ou MySQL. De novo, precisaria ter uma noção melhor do MVP para dar uma opinião mais concreta.
No-code/Low-code foram feitos pra isso. Mete um bubble ou outsystems e seja feliz. Depois que conseguir ter sucesso com MVP, aí tu pensa em Banco de dados, ORM etc.