pchemu4ka

kwork.ru специализируется на изолированных мелких работах.

Слово "идея" - маркетинговый буллшит в мире стартапов. Нет у вас никакой идеи и ни у кого ее не было. Давайте разберемся с тем, что такое стартап и вы поймете, как и где защищать идею.
Стартап - это проект (не обязательно новая компания, есть и стартапы в рамках крупных корпораций), который прокладывает новую бизнес-модель, которая раньше не существовала.
Например, вы можете построить ресторан. И до вас стопицот других людей это сделали. То есть, основываясь на их опыте, вы можете просчитать риски и примерные доходы, рост. В стартапе вы первые (или параллельно с вами есть еще те, кто не закончил решение проблемы или не донес его до всех). Статистики для вас нет. Взлетит? Не взлетит? Никто не знает. Просчитывается очень мало, даже при соблюдении всех технологий и этапов роста.

Теперь к идее: нет такого понятия. Вы можете сделать восхитительную штуку. Никто ее не купит, потому что ничего не заставит его сделать несколько лишних телодвижений, чтобы это получить. Потому что у клиента ничего не болит. Потому что это будет игрушка на день, как программа Google Earth или типа того.

Но вместо идеи есть два других понятия: проблема (боль клиента) и решение проблемы. Сегодня клиенты как-то уже решают эту проблему. Им же надо как-то с ней жить. Но решают может вручную, неоптимально или хотели бы решение более гармоничное. И готовы за это решение платить.

Поэтому, прежде, чем начинать тратить деньги, стартапер сначала проверяет есть ли такая проблема и нужно ли такое решение (этап Customer Development).

А теперь скажите, что у вас там воровать, если добрая сотня человек сегодня бьется над решением этой проблемы?

Вот давайте посмотрим. Не говорите свою идею. Скажите только какую проблему нужно решить. И мы вместе посмотрим, не решена ли она уже. Потому что именно это и будут смотреть инвесторы.

Любого заказчика в первую очередь интересуют 2 вещи:
a) сколько ресурсов ему потребуется на проект?
b) почему именно столько?

Общий подход - декомпозировать задачи указанные в тз.
До какого уровня - зависит от конкретного заказчика и размеров проекта.
Моя субъективная точка зрения - на стадии продажи нужно декомпозировать условный средний проект до 30-60 задач.
Больше - слишком накладно, меньше - слишком большие погрешности.
Но опять же, это мой опыт и мои типовые проекты.
Если кто-то ERP системы пишет - там и 500 строк в оценке не много.

В чем именно выражается оценка каждой задачи - сразу в деньгах, или в часах умноженных на деньги - личное дело. Я считаю что оценка в часах умноженная на рейт заходит лучше.
Вопрос "почему рейт именно такой" - заказчики как правило не задают.
Рейт такой, потому что такой рейт по рынку.

PS В целом InoMono написал правильно.
Заказная разработка как бизнес практически не масштабируется горизонтально.
Хорошие менеджеры хотят очень много денег, а большая команда разработки быстро съедает всю прибыль при малейшем простое.
Выход - только вертикальное масштабирование.

PPS посмотрите еще Стоит ли основать веб-студию?

UPD

Чтобы работало системно, нельзя подходить из серии - пробуйте продавать максимально насколько лично получится

- ваши слова.

Как это делается системно - я написал выше.
Как это делается не системно - написал InoMono
В чем вопрос то?

По какой формуле считать так, чтобы было понятно и прозрачно для заказчика?

Заказчику понятно когда вместо "я сделаю вам сайт за 200 часов" ему присылают (все цифры условно):

• составление тз 20
  
• согласование тз 5
  
• скетч дизайна 120
  
• определение фирменного стиля 80
  
• дизайн на основе скетча и фирменного стиля 60
  
• верстка html 40
  

по желанию крупные блоки тоже расписываются, вместо "верстка html 40" - верстка каркаса, верстка главной страницы, верстка страницы X...

Или вопрос "какая норма доходности"? У всех по разному. от двухзначных до пятизначных цифр.

Если составить семантическое ядро и просуммировать спрос по каждому ключевику с помощью Я.Вордстата, будет ли эта информация правдоподобной?

Если правильно составите и правильно проссумируете - то да, будет очень правдоподобной.
Можете даже конверсию прикинуть в первом приближении по пессимистическому прогнозу -- 1-5 заказов с сайта на 1000 запросов с вордстата в нужном регионе. И минимум 1 гарантированный клиент на каждые 10000 запросов.

Самый простой и быстрый вариант - просто сбрасывать все реквесты в файл (можно прямиком из nginx log, но с конвертацией перед отправкой), потом этот файл и отдавать, опять же через nginx.
Будет держать 1000млн записей в сутки и более (зависит от железа).

Если вы в Москве, то Школа менеджеров Яндекса может стать неплохим опытом. Набор, кстати, сейчас открыт

Изучение искусственного интеллекта?

На курсере есть годный курс. https://www.coursera.org/learn/machine-learning

Интересует робототехника, дроны, квадрокоптеры, и т. п

Тогда ещё нужно изучить основы электроники и программирования микроконтроллеров

в математике полный ноль, увы

Тоже придётся подтянуть

Работаете в ветке dev, периодически вливая ее в master. Для крупных задач (не входящих в один коммит) делаете отдельные ветви из dev.

Вливая dev в master, делаете это с ключом --squash как то так:

git checkout master
git merge --squash dev

Тут теоретически могут быть конфликты, если вы делали коммиты в masterпараллельно с dev, которые вам надо разрешить, а после уже добавляете и делаете один большой коммит:

git add -A
git commit -m "Merged dev: %кратко (или нет) основные изменения%"
git push

А чтобы не мозолили глаз висящие коммиты с логической незавершенностью, их можно сливать их перед merge с помощью интерактивного rebase:

git checkout dev
git rebase -i master

Откроется редактор, в котором будет список коммитов ветки dev. Здесь можете слепить ненавистные коммиты с помощью команды squash (и тогда вам предложат отредактировать сообщение) или fixup (тут не предложат) и потом сделать git push --force (для одного не критично, в толпе лучше использовать --force-with-lease.

Или есть еще вариант - лепить к предыдущему коммиту сразу с помощью git commit --amend

Ну и после merge уже можете на master лейбл версии повесить.

Бесплатная и очень крутая (для Винды и Линукса — что для меян очень важно):
Pingendo

Описание с видео работы программки для 3 версии, 4 чуть отличается по дизайну
https://maksfedorov.ru/blog/all/prototipy-saytov-v...
для 4 версии также есть веб-интерфейс

Кликабельно

https://pinegrow.com/ (хоть и не бесплатен, но есть варианты бесплатного использования)

UPDATE:
https://mobirise.com/bootstrap-builder/

https://bootstrapstudio.io (25$ - не критично)

Очень просто, демонстрируйте видео с рабочего экрана