Evgin

Заказчика лучше удерживать другими способами, например, качеством работы.
По мне так большинство и так достаточно ленивы, чтобы менять исполнителей. Это же каждый раз риск, трата времени.
Кроме того, малоизвестные технологии скорее всего и развиваются медленно, имеют риск умереть. Представляете, как будете оправдываться перед заказчиком, почему не можете сделать ту или иную фишку, которая есть уже у всех его конкурентов. Что Вы ему скажете?

Привязывать к себе заказчика надо не использованием специфичных технологий, а качеством и сервисом.
По опыту, стоимость разработки проектов такого рода - много меньше стоимости их годовой поддержки. Соответственно захотят от вас избавиться - найдут человека который быстро перепишет все с нуля.

Помимо этого есть вопрос репутации. Довольный клиент рассказывает 1-2 людям. Недовольным - 10рым.
Это относится к вообще любым серым приемам. Можно и исходный код зашифровать, что уж стесняться.

stackoverflow.com/questions/18681600/where-is-the-...

1. Напишите требование об оплате задолженности по договору авторского заказа в двух экземплярах. Примерно так : www.logos-pravo.ru/page.php?id=1554
С этим требованием приходите к заказчику и просите подписать оба экземпляра. Один для вас, в качестве доказательства о соблюдении норм досудебного разбирательства. Если заказчик откажется подписать, то отправьте почтой заказным письмом, вам потом придет уведомление о доставке или о том, что заказчик не получил письмо, но если он не получит письмо, то это его проблемы, уже можно будет обращаться в суд.
2. Составляете судебный иск об оплате задолженности по договору авторского заказа, прикладываете доказательства, то что сайт уже на хостинге для вас отличное доказательство выполнения ваших обязательств по договору. Нужно будет нотариально заверить скриншоты работающего сайта. Ещё понадобиться приложить копию договора, копию требования об оплате задолженности или корешок от почты о доставке письма. Там есть ещё небольшие нюансы, что нужно прикладывать, в основном остались копии всех документов по числу сторон.
Я не адвокат(бывший судебный пристав), но обычно последовательность такая. Если будете обращаться в суд, то лучше конечно использовать помощь адвокатов для правильного составления документов.

1. Бланшет, Саммерфилд - Qt4 Программирование GUI на С++. 2ed. - 2008
2. Шлее Макс - Профессиональное программирование на C++. +CD. Qt 4.8. (В подлиннике) - 2012
3. Марк Саммерфилд - Qt Профессиональное программирование (High tech) - 2011
4. Андрей Боровский - Qt4.7+. Практическое программирование на C++ - 2012
5. Юрий Земсков - Qt4 на примерах

Первая книга от создателей Qt, в первых главах рассмотрено создание приложения для работы с таблицами (этакий мини Excel). Так что в прямом смысле за день можно разобраться во всех тонкостях создания подобных приложений.
Вторая книга от известного в Qt-сообществе программиста, очень подробный и толстый справочник по виджетам, их описание и примеры использования. Имеется несколько глав по JavaScript/QML/QtQuick. Однозначный Must Have.
Третья книга от одного из программистов, разрабатывающих Qt. В ней рассказано о профессиональной разработке приложений. В чем-то является продолжением первой книги.
Четвертая книга от отечественного программиста, рассмотрены в основном принципы разработки сложных приложений. Отдельный разделы посвящены программированию трехмерной и интерактивной графики, баз данных, многопоточных приложений и созданию собственных виджетов.
Пятая книга на мой взгляд уже устарела. Её вполне заменяет Макс Шлее.

Это все книги по Qt 4.X.X на русском языке, известные мне (не считая редакций). Если кто-то знает ещё, пожалуйста отпишитесь.

По Qt 5 книг пока нету. Макс Шлее сказал, что начнет работу над новой книгой с выхода версии Qt 5.2. По поводу книг для Qt 5 см. ответ ниже. Но не стоит забывать, что у Qt документация одна из самых лучших и вполне способна заменить книгу. Поэтому настоятельно рекомендую пользоваться Qt Assistant при возникновении затруднений.

По C++ рекомендую конечно классику:
Прата С. - Язык программирования С++. Лекции и упражнения - 2011

Я понимаю, что linux-прошлое накладывает свой отпечаток, но вот вам совет: не трогайте ничего.
Оно всё отлично работает и из коробки.

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

По поводу организации команды - это должно определиться внутри команды. Вы же менеджер. Введите дейли/стэндап/планинг митинги, скамы/канбаны, continious integration и delivery... Технические моменты можно определить командой.