Технический и архитектурный аудит, который даёт решение
Провожу технические аудиты и архитектурные разборы для компаний, которым нужно независимое чтение системы до бюджета на рерайт, вендора, фонд-нарратив или программу ИИ. На выходе — решение: что делать в каком порядке, чего не делать и на каких свидетельствах стоит рекомендация. Читаю репозиторий, путь выкладки, инциденты и процесс. Не произвожу дамп линта на 200 пунктов. Можно заказать как фиксированный разбор или как первую фазу внедрения.
Кому это подходит
- Фаундерам и CTO до крупной траты (рерайт, вендор, ИИ, интеграция после сделки).
- Руководителям инженерии, которым нужен внешний голос в застрявшем архитектурном споре.
- Операторам технической проверки продуктовой компании — с оговоркой: я один старший инженер, не команда Big Four.
Когда аудит — правильный артефакт
- Две внутренние фракции уже выбрали стеки; нужен третий взгляд, опирающийся на код.
- На столе предложение вендора, и его нечем опровергнуть.
- Подозреваете, что узкое место — не «больше разработчиков».
- Внедрение ИИ одновременно тема совета и тема продакшена.
Какой объём беру
- Разбор архитектуры и кода продукта или платформы.
- Поставка и эксплуатация: CI, среды, наблюдаемость, форма инцидентов.
- Наследие и CMS: что можно удавить, а что на самом деле нормально.
- Готовность к ИИ / LLM: данные, контракты, стоимость и существует ли сценарий.
- Письменный бриф для руководства, который не оскорбляет инженерную команду.
Как проходит аудит
Доступ, короткий старт, чтобы назвать нужное решение, затем чтение системы в ограниченное время. В первый день скажу, если доступа недостаточно для сильной рекомендации. Находки упорядочены решением, а не театром CVSS. Вы получаете разбор и документ. Внедрение — отдельное соглашение, если захотите: я не протащу контракт на сборку внутрь аудита.
Измерения аудита
Смотрю теми же измерениями, как если бы потом сам взял пейджер.
Соответствие ограничению
Форма системы совпадает с настоящим узким местом — или с модой прошлого года?
Корректность при отказе
Идемпотентность, валидация, задачи и что происходит, когда зависимость умирает.
Стоимость изменения
Насколько дорога типичная фича, смена схемы, новый инженер?
Безопасность и данные
Аутентификация и авторизация, секреты, тенантность и — для ИИ — что покидает контур.
Эксплуатация
Логи, трассы, выкладки, откаты, хозяева. Система, которую никто не может отладить, уже лежит.
Качество свидетельств
Что удалось проверить в отведённое время, а что остаётся гипотезой. Помечу и то и другое.
Чего не сделаю
- Липовые баллы, которые изображают научную точность, которой нет.
- Только SAST-дамп под видом архитектуры.
- Отчёт, чтобы напугать покупателя рерайтом, который я потом продам.
Результат
- Памятка решения: контекст, находки, варианты, рекомендация, риски.
- Техническое приложение, с которым инженерия может спорить.
- Предлагаемая последовательность на 30/90 дней, если действие оправдано.
Избранные проекты
- Genie Platforms – Разговорная AI-платформа для продаж, RevOps и GTM – AI-SDR внутри существующих процессов выручки.
- Mindshine – Платформа голосового и текстового поиска (TIVA Data / Knowledge Base): доступ к данным независимо от источника.
Связанные услуги
- Архитектура ПО – Системный дизайн живых продуктов: чему существовать, где границы и как система отказывает.
- Модернизация систем – Перенести живую платформу на актуальный стек поэтапно, с целостностью данных, а не большим взрывом.
- Техническое лидерство – Постоянный старший взгляд на архитектуру и выпуск для команд, которым нужен рычаг, а не ещё один штатный найм.
- Интеграция ИИ – Модель внутри существующего процесса — с контрактами и выходом, а не чатбот рядом с продуктом.
Связанные заметки
Вопросы, которые задают
Это технический due diligence для сделки?
Могу дать инженерное чтение. Я не финансовая и не юридическая команда и не подпишу отчёт, который притворяется иным. Для полной проверки при покупке компании за столом всё равно нужны остальные.