Explícame cómo dimensionarías y entregarías una funcionalidad que toca la base de datos, la API y la interfaz.

Trocéala en vertical y entrega por etapas en vez de construir tres capas en paralelo. Empieza por el modelo de datos y una migración aditiva, luego la API con pruebas de contrato, luego la interfaz detrás de una feature flag. Consigue pronto que un caso estrecho funcione de punta a punta, porque ahí es donde las suposiciones equivocadas salen a la luz de forma barata. Mantén los pull requests lo bastante pequeños como para que alguien pueda revisarlos bien de una sentada.

Antes de escribir nada quiero la versión más pequeña que sea de verdad útil, porque la mitad de lo que se especifica no hace falta en la primera entrega. Luego hago una porción vertical fina: un campo, un endpoint, una pantalla, funcionando de punta a punta en un día o dos. Ahí es donde descubres que el modelo de datos está mal, y descubrirlo el segundo día no cuesta nada comparado con el noveno. Las migraciones van primero y siempre son aditivas para poder entregarlas antes que el código que las usa. Si otra persona construye la interfaz, acordamos pronto el contrato de la API y trabaja contra una simulación o un esquema tipado para que nadie se quede bloqueado esperándome. En cuanto a pull requests, apunto a cambios que un revisor pueda sostener en la cabeza: migración y modelo en uno, endpoint y pruebas en otro, interfaz en un tercero, todos fusionados detrás de una flag apagada. Luego la encendemos internamente y después para un porcentaje pequeño. Entregar a oscuras así me ha salvado más de una vez cuando la carga fue peor de lo esperado.