Me explique como você dimensionaria e entregaria uma funcionalidade que toca o banco de dados, a API e a interface.

Fatie na vertical e entregue em etapas em vez de construir três camadas em paralelo. Comece pelo modelo de dados e uma migração aditiva, depois a API com testes de contrato, depois a interface atrás de uma feature flag. Faça um caso estreito funcionar de ponta a ponta cedo, porque é ali que premissas erradas aparecem de forma barata. Mantenha os pull requests pequenos o bastante para alguém revisar direito em uma sentada.

Antes de escrever qualquer coisa eu quero a menor versão que seja genuinamente útil, porque metade do que é especificado não é necessário no primeiro release. Depois eu faço uma fatia vertical fina: um campo, um endpoint, uma tela, funcionando de ponta a ponta em um ou dois dias. É ali que você descobre que o modelo de dados está errado, e descobrir no segundo dia não custa nada comparado ao nono. As migrações vêm primeiro e são sempre aditivas para poderem ir antes do código que as usa. Se outra pessoa está construindo a interface, a gente acorda o contrato da API cedo e ela trabalha contra um mock ou um schema tipado para ninguém ficar bloqueado me esperando. Sobre pull requests, eu miro em mudanças que quem revisa consegue segurar na cabeça: migração e modelo em um, endpoint e testes em outro, interface em um terceiro, todos mergeados atrás de uma flag desligada. Depois a gente liga internamente, depois para uma pequena porcentagem. Entregar no escuro assim já me salvou mais de uma vez quando a carga foi pior do que o esperado.