Есть две крайности, которых лучше избегать:
1. красивая и исчерпывающая документация требует колоссальных ресурсов на поддержку
2. сложно воспринимаемый код, без малейших подсказок с чего все начинается и чем заканчивается

Стандартные решения:
1. самодокументируемый код, составленный так, что читающий может понять что для чего и в какой последовательности работает.
2. описание интерфейсов (назначение метода, тип/суть параметров и т.п.) в форме комментов в коде.
3. автоматическая документация (генерится из комментариев) - эффективно, только если сам код закрыт.
4. модульные тесты, фиксирующие требования к коду и демонстрирующие его использование.
5. описание высокоуровневого дизайна (High Level Design, HLD), описывающий какие элементы существуют, их взаимосвязь друг с другом и основные сценарии взаимодействия.

Работающая документация - это компромисс из этих практик, релевантный конкретной ситуации.

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

В вашем случае хорошо будет объединить поддержку и Kanban. Процесс при этом может выглядеть следующим образом:
1. Через поддержку клиенты оставляют заявки, где описывают что им нужно.
2. Менеджер разгребает эти заявки, уточняет их (добавляет нужную информацию) и может как-то классифицировать, например, Сайт или Инфраструктура или еще как-то. Менеджер может оценивать сложность заявок по шкале X, L, M, S.
3. Члены команды берут по мере возможности себе те задачи, которые подходят им по классу и по оценке сложности. Выполняют работу и перетаскивают карточку в состояние "Выполнено".
4. Менеджер принимает выполненную работу и отмечает заявку как завершенную, либо отклоняет ее на доделку/переделку. Заказчику уходит письмо о том, что его заявка выполнена, ну и дальше он смотрит, отклоняет или принимает ее решение.

В этом процессе минимум взаимодействия, все видно на Kanban-доске. Видно где затык, кто сидит ковыряет в носу и т.д. В качестве инструмента, в котором такой процесс можно организовать, могу посоветовать devopsboard.ru

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

Образовательные учреждения - это не бирюзовые организации, прикольные фишки внедрять они сами никогда не станут, пока не будет регламента или приказа на это сверху. А вот инициатором таких внедрений могут стать ИТ-подразделения (в любом крупном ВУЗе такие есть). Вам нужно говорить с аналогом CIO в корпорациях, это кто-то типа зам. проректора по ИТ ВУЗа. Ему нужно показать реальные выгоды от внедрения, тогда он возможно пойдет уговаривать сделать приказ на внедрение этого в учебный процесс.

Сама по себе модель SaaS для большой/неповоротливой организации выглядит сомнительной. Идея SaaS - надо пользуйся, не надо - не плати. Если для внедрения продукта требуются изменения во внутренних бизнес-процессах организации (в учебном процессе, например), то ради какого-то стартапа это делать вряд ли будут. Нужно решение, которое можно поставить и обслуживать своими силами в течение лет 5 - 10. Убедитесь, что ваше решение не требует изменения существующих бизнес-процессов/регламентов/навыков персонала. Либо это другая история.

Большинство образовательных учреждений в РФ государственные и подпадают скорее под категорию социального предпринимательства. Это не сосвем бизнес и скорее всего не для стартапа без серьезных внешних инвестиций. Убедитесь, что ваша бизнес-модель реалистична. Возможно, ВУЗы в большинстве не готовы даже бесплатно использовать ваши продукты, о каком бизнесе тут может идти речь?