Есть разные методологии. Но обычно они сходятся в идее, что сначала хорошо бы подумать о том:

• что именно надо сделать в первую очередь (и чего не надо делать в первую очередь)
• для кого мы это вообще делаем (кто и как этим в итоге будет пользоваться).

Смотря для кого проект Если для людей то гипотеза и её проверка. После готовим список фич Дизайним проект и проверяем как он обществу. И только после этого, что-то программируем.

Если для себя и друзей, просто подготовить тз или схему или экраны и вперёд реализовывать

Идея, дизайн, разработка, публикация

Сперва идея должна стать схемой. Цель схемы: отразить логику предполагаемого проекта (её разделение в зависимости от количества задач). Если проект простой, то особой декомпозиции на периферийных уровнях не потребуется. В противном же случае лучше отдельно нарисовать структуру раздела. На основе имеющихся рабочих схем можно уже переходить к разработке фронта и далее - бэка. Для полноциклового разработчика в единственном лице этот порядок может быть любым, но, как по мне, - с готовой вёрсткой лезть на бэк вернее). Не все проекты привлекают дизайнеров (а напрасно). Когда есть уже нарисованное - это хорошо, а когдо есть классно нарисованное - это классно. Тут - без оговорок: есть дизайн-> верстаем по дизайну, иначе более упрощённый вариант. Как то так.

Маркетинг->SEO->Дизайн->Вёрстка->фронтИбэкРазработка