Qual a ordem correta para fazer um sistema fullstack?

Pra mim, o desenvolvimento do sistema sempre começa na análise de requisitos, dai crio o escopo da aplicação, o que ela deve fazer e, eventualmente, o que não precisa ou não deve e então crio um esboço da regra de negócio para atender aqueles requisitos.

Daí, com esboço no "papel", estruturado e revisado, penso na melhor tecnologias ou linguagem pra atender os requisitos e regras de negócio.

Só depois disso tudo é que começo modelando DB > back > front (aqui vai de projeto pra projeto. As vezes faço wireframes, as vezes vou direto pro código).

Mas também já tive projetos em que fui back > front > db. E também já tive situações em que foi melhor ir front > db > back.

Acho que existem formas mais e menos eficientes, mas também dependendo do seu background e habilidades que tem mais familiaridade. Não adianta seguir uma forma que em teoria seja mais eficiente no geral, mas que no seu caso te trave. Melhor começar do que não fazer.

Como unico desenvolvedor na empresa em que eu trabalho. Eu faço a sequencia: BD, Backend e Frontend. Mas sempre fazendo por módulos. Vou fazer cadastro de usuário? Faço o BD, Backend e Frontend. Agora vou fazer o cadastro de funcionário, por exemplo, faço a parte do BD, backend e Frontend.

Como não gosto de frontend, não faço prototipação, wireframe nada, vai tudo no firstcode.

Não sei se existe a 'forma correta', mas acredito que exista algumas melhores que outras. A melhor forma de desenvolver um sistema pra mim é:

1 - Validar a ideia, verificar se vai agregar valor para o seu cliente e isso vai se transformar em lucro.

2 - Pensar nas funcionalidades do sistema e separá-las em módulos para construir o banco de dados. Aqui você já terá um esboço de como as coisas vão funcionar, quantas páginas, relacionamento entre informações, tudo o que precisa para passar pro designer.

3 - Desenvolver o design do sistema pensando na fácil utilização por parte do cliente, pois isso pode te fazer ganhar mais clientes ou perdê-los. O usuário comum não pode sentir dificuldade de utilizar o seu sistema.

4 - Com o design em mãos, é hora de desenvolver o frontend. Aqui você vai deixar tudo preparado para o backend dar vida ao sistema.

5 - Desenvolver a regra de negócio, o backend em si e fazer a coisa funcionar.

Dessa maneira o meu backend se adapta ao meu frontend. Lembra da usabilidade? Então! Se eu crio primeiro o backend o meu frontend vai precisar se adaptar ao que já está pronto, e me deixa engessado na questão de usabilidade.

A sequência no geral é uma (BD, BACKEND e FRONTEND), mas não que seja a correta Tem projeto que preciso mostrar algo rápido no designer então tenho que adiantar, faço o banco inicialmente, só a parte do login e no backend também e já parto para o visual

Mas no geral é como você comentou mesmo, banco, backend e front, mas não precisa fazer o banco todo, você pode fazer uma parte, depois também o backend e depois o front e assim vai indo até finalizar.

Até porque se colocando no lugar do cliente, ele ver banco ou backend não vai adiantar muito, a gente conhece e dá valor, mas o cliente quer ver a cara do sistema e não códigos e tabelas 😁

Abraço

Tente usar TDD. Se nunca fez, é uma experiência que eu acho totalmente valida. A ordem ficaria: Design - Testes e2e Frontend - Frontend - Testes integração backend - Testes de unidade backend - backend - BD Tirando a parte do design, essa é a ordem seguida no livro TDD com python

eu faço nessa ordem: design->frontend->backend->bd

Comece sempre pelo negocio! Defina as regras, os requisitos, modele o negocio antes de pensar nos detalhes.

Como diz o Uncle Bob: Banco de dados é um detalhe!