Технический и архитектурный аудит, который даёт решение

Провожу технические аудиты и архитектурные разборы для компаний, которым нужно независимое чтение системы до бюджета на рерайт, вендора, фонд-нарратив или программу ИИ. На выходе — решение: что делать в каком порядке, чего не делать и на каких свидетельствах стоит рекомендация. Читаю репозиторий, путь выкладки, инциденты и процесс. Не произвожу дамп линта на 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 для сделки?

Могу дать инженерное чтение. Я не финансовая и не юридическая команда и не подпишу отчёт, который притворяется иным. Для полной проверки при покупке компании за столом всё равно нужны остальные.