Помимо пуленепробиваемости надо сделать отображение на каждую возможную ошибку серверную и клиентскую.
Можно дополнить onFail у $.ajax, чтобы обрабатывать специальный параметр с ошибкой.
Думаю, обойдемся шлепаньем бабла, или ворнингом в начале страницы.

Надо придумать файловую структуру.
У приложения будет несколько входных точек, для оптимизации.
Нужен механизм подключения зависимостей из какого-то библиотечного хранилища. Скорее всего это будет просто require_once.
Скажем, /libs/ - храним весь основной рабочий код, включая функции работы с БД.
Внутри /libs/ код можно разбить по папкам по направленности работы: system, db, app/order, app/user.
При этом будет bootstrap, чтобы была глобальная, железобетонная обработка ошибок.
Там же стоит обработать текущего пользователя, перепроверить роль.
В шаблонах нужно блочное решение, т.к. мы будем асинхронно подгружать карточки заказов.
Статику храним в public_html.
Можно попробовтаь точки входа тоже разместить там же, но тут тогда надо будет не забывать в каждой точке входа навешивать обработку ошибок, слишком рискованно.
Лучше сервером делать редирект с урлом, в котором будет ключ-ссылка на файл. Но в этом случае должен быть надежный роутер, который не взломать никак.

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

Нужно реализовать механизм доставки событий на клиент.
Например, создали новый заказ, или завершили старый, или изменилось состояние счета в другой вкладке, эти изменения должны отобразиться как можно скорее.
По-хорошему надо бы использовать комету, но так как надо использовать php, да еще без ооп, то прийдется обойтись периодической аяксовой долбежкой "а не появились ли новые события".
Надо придумать таблицу с событиями - timestamp, ключ события, и кому оно может быть интересно (это нетривиальный момент).
Если новые заказы - то нужно всем исполнителям шлепнуть новые заказы в начало списка.
Если заказы завершены, то нужно пометить их завершенными, а потом плавно спрятать.
Если обновлен счет, то нужно просто заменить цифру. Причем надо здесь дискардить все события обновления счета, кроме последнего, чтобы было по-надежнее.

Надо этот момент хорошенько продумать на данном этапе.

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