Большой проект на С. Как строить работу чтобы не завалило кодом?

1) Разбиваем по категориям, каждую категорию - в свою папку. Если надо - еще подпапки.
2) Общий или старый код вынести в библиотеку, подключать только .h + .lib
3) Использовать систему контроля версий.
4) Ввести лимит по количеству строк на файл, перераспределять код таким образом, чтобы в одном .c файле было не больше 1000 строк (имхо даже 500 на с уже много. )

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

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

По самому проекту тебе ответил уже Владимир Дубровин, а вот по малой части надо стремиться к декомпозиции (разложению) на исполнители.

В одном .h файле описываешь интерфейс объекта, например, стека

void stack_start();
int stack_push(int value);
int stack_pop();
int stack_isempty();
int stack_topr();
int stack_topw(int value);
void stack_del();
void stack_end();

Дальше в .c файле пишешь реализации этих методов (сами функции и статические (закрытые в файле) переменные, которые им нужны для внутренней работы). И потом, чтобы подключить стек, ты просто подключаешь его .h файл и используешь эти методы.
(Это пример; на самом деле, делается набор методов, который можно применять к разным стекам, где соответствующий стек (структура) просто передаётся в метод первым аргументом.)

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

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