Этап подготовки к разработке сайта. Когда оценивать бюджет и заключать договор?

Когда-то давно тоже был опыт создания сайтов по ТЗ и это была боль - приходилось делать долгосрочные эстимейты (которые никто никогда не угадывал), тратить кучу времени на ТЗ, чтобы не пропустить ни одной детали, затыкать заказчику рот этим ТЗ когда он через месяц менял свое мнение.... ну и т.д.
С тех пор только спринты - в начале приблизительно оцениваем сложность проекта чтобы определиться с инструментами разработки и обязуемся через N недель выдать MVP. А дальше "любой каприз за Ваши деньги" - новые фичи == новые спринты == платите. Клиенту останавливаться после первого же спринта смысла нет - он заинтересован в готовом продукте, а смена исполнителя это доп. траты. В то же время и у клиента и у исполнителя есть шанс не продолжать сотрудничество после определенного спринта если вдруг испортятся отношения. Клиент сам рассчитывает за что он платит и когда остановиться.
Я правда уточню, что в последнее время я работаю в большой компании и в моем случае "клиенты" - это стейкхолдеры, которые работают в этой же компании. Но в данном случае они мало отличаются от "аутсорсного" клиента, потому что они являются заказчиками проекта, у них есть определенный бюджет и наше сотрудничество выглядит именно так как я описал выше.

исходя из опыта прикидывать примерное количество часов на разработку - умножать на свою почасовую ставку - корректировать по формуле Бобука и давать такой эстимейт.
Либо давать точные эстимейты на типовые проекты, основываясь на предыдущих работах, и предупреждать клиентов, что правки НЕ багов, а вкусовщины оплачиваются.

Берите плату за прототипирование.

1) Сразу не вникая очень глубоко на основе предыдущего опыта можно назвать заказчику примерные рамки цены от ... и до ... и если заказчика этот диапазон устроит, то можно продолжать разговор. Некоторые на этом этапе отваливаются, это воздухогоны, у которых денег нет, а ходят по базару и просто прицениваются. Или же спрашивать у заказчика бюджет проекта, на какую сумму он рассчитывает, тогда думать только в пределах бюджета.
Т.е. смысл в том, чтобы на самом первом этапе отсеять все пустышки, чтобы не тратить на них свое время.
2) Для тех кто не отказался, нужно делать бриф и список функций или модулей и считать уже более точно ценник. На этом этапе можно договариваться с заказчиком Цена +/- 10% на непредвиденные ситуации. Обычно здравомыслящие заказчики понимают, что проект оценить на старте до копеек невозможно. Уже можно делать договор и просить предоплату.
3) И когда уже все будет до мелочей расписано, тогда уже можно смотреть, и если сильно ошиблись не в свою пользу, то либо разговаривать с заказчиком и менять цену (доп. соглашение к договору), либо отказаться (в договор надо забить пункт для варианта отступления).

Для заказчика все должно быть прозрачно и желательно не просто называть ему цену, а подробно расписывать калькуляцию, что делается и сколько стоит. Так заказчик будет уверен, что его не обманывают, а если жалко денег, то отдельные пункты он может не делать.

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