Я думаю тут имеет смысл применить теорему эскобара для решения данного вопроса

Сила в ньютонах

+

Dmitriy K (4) увеличил репутацию Иван Повстен (10)

Приоритетные оформительские баги

Баги бывают разные  и это реально проблема, когда в команде наглухо не закрыта потребность тестирования. А обычно она не то, что наглухо не закрыта, а вообще тестирование выполняет функцию фигового листочка.

Главную ведь функцию прил/продукт выполняет? Да. Значит на мелочные ошибки можно не обращать внимания. Основная-то функция выполняется!!!

Вот с момента, когда Ты так подумал, начинается злое волшебство. Уважаемый Заказчик начинает думать так: "вот они накосячили даже простейшими опечатками, тупо их не вычитав! если они в мелочах небрежны, то уж что говорить про ключевые функции???" И всё-о-о-о-о.... Твой кредит доверия мгновенно провалился в такой овердрафт, что Тинькофф по тебе плачет.

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

Так что вычитка текстов, оформление - наше всё. Дизайн - продающая штука, но только если под капотом у Тебя не полная жопа (это не размер! это наполненность!) - тут уже можно пить не чокаясь сразу.

Дмитрий, мне кажется, вы занимаетесь дедукцией, и слишком обобщаете

Думаешь, перегибаю палку?

да, похоже на попытку надавить на болевые точки и спровоцировать обсуждение

Ну это точно нет. Я скорее хотел не потерять мысль важную. Обсуждения - дело второе. Полезное конечно, но необязательное.

😉

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

зачем такие клиенты нужны?

Если клиент докапывается, значит исполнитель не выстроил с ним нормальные отношения. Управление ожиданиями, вот это вот все. Цель - не бюджет пилить а однозначно понимать что мы делаем и сколько это будет стоить.
Я тут видел реакцию заказчика, с которым разработка через 3 года стала разговаривать и показывать что напилили. Шок, недоумение, печаль. Полгода стабилизации, прежде чем с продуктом стало возможно работать.

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

Отличная иллюстрация к теме "СТО из девелоперов", кстати.
Программист выбирает Rust за красоту концепций, "модность" и итоговый performance (если осилил).
СТО - Go, за простоту, "кондовость", отличный тулинг из коробки и доступность разработчиков на рынке.

Надо сделать опрос Go vs Python ;-)

История: люди продавали SaaS на Python. Дела шли неплохо и их заметила крупная лавочка, вышедшая на них с темой "ваши интернеты - это хорошо, но нам нужно иметь контролируемое админами решение внутри периметра".
И загрустили тогда хипстеры, ибо отдавать все свои исходники не хотелось им.
Может сейчас есть решение, но тогда не было.

Какой прок от подчищенных исходников без документации и обучения если там хотя бы 20000 строчек?  Клиент не сможет ни развивать,  ни поддерживать - а контракт на поддержку должен быть дорогой и включать условия что контрольные суммы не меняются или это уже кастомная разработка.

Это коробочное решение с простым и понятным API.
Мало кто готов просто так отдать свою интеллектуальную собственность. Шанс, что исходники банально продадут конкурентам весьма ощутим.

​​Есть Android-разработчик. Кому?