Архитектурный подход к построению вашего продукта не означает "долго". Он означает "учитывая вектор развития".
Вы должны определиться со своими целями, прежде чем начнёте куда либо двигаться, а далее на каждом шаге проверять придерживаетесь курса или нет. Для этого нужно выработать принципы построения проекта и научиться отвечать на вопрос "зачем?". Например, зачем я использую СУБД, а не пишу данные в файл. Если не можете ответить на вопрос "зачем", то вероятно у вас нет необходимости в СУБД.
На уровне принципов архитектурный подход определяет и правила ведения документации, и уровень детализации проекта и т.д.
Делая стартап вы можете сильно упростить требования к ведению проекта, а разрабатывая космический аппарат, наоборот усложнить.
Есть разные техники, помогающие выработать нужные привычки, например "проговаривание" - "я делаю этот класс потому что ..."
В целом архитектурный подход ничуть не "дольше", чем "делаем как получится". Наоборот, он призван уменьшить энтропию вашего проекта и увеличить синергию команды.
Проблема лишь одна - нужно учиться, но это сложно, куда проще сказать "нам и так сойдет", а потом убедить себя, что все так работают и ничего.