diff --git a/case-study.md b/case-study.md
new file mode 100644
index 0000000..892e05d
--- /dev/null
+++ b/case-study.md
@@ -0,0 +1,36 @@
+# Case-study оптимизации рабочего проекта
+
+## To start
+
+- что за проект
+  * программный комплекс, состоящий из высоконагруженной веб-платформы (15-80 млн реквестов в сутки) и мобильных приложений для оказания услуг учебным заведениям, работодателям и студентам, связывающий эти три группы пользователей воедино.
+- как долго уже разрабатывается
+  * проекту около 10 лет (ruby on rails монолит с позже добавившимися минисервисами (rails engines) и теперь преобразуемый по методолгии DDD в packages)
+- как дела с перформансом
+  * неплохо, т.к. ведется мониторинг всех систем и непрерывно внедряются улучшения по снижению времени отклика, оптимизируются запросы к БД, рефакторится старый код
+- есть ли мониторинг
+  * да, основные популярные системы: datadog, bugsnag. происходит трекинг всех пользовательских путей. внедрена система Service Level Objectives, налажена работа с инцидентами (интеграция мониторов в slack + PagerDuty)
+- можете ли вы навскидку предположить где в проекте есть что оптимизировать
+  * безусловно, три точки роста - это оптимизация запросов к БД (борьба с N+1, загрузка связей на раннем этапе, кэширование), облегчение сборки фронтэнда и оптимизация времени выполнения тестов.
+- какова ваша роль в проекте, как давно работаете, чем занимаетесь
+  * фулл-стек разработчик с фокусом на бэкэнде, в этом проекте около 9 месяцев, основная работа на данном отрезке времени была посвящена локализации продукта для выхода на европейский рынок
+
+### О чём интересно рассказать
+
+- расскажите об актуальной проблеме;
+  * одна из последних оптимизаций была направлена на снижение размера бандла фронтэнд части за счет перекомпоновки загружаемых переводов
+- расскажите, какой метрикой характеризуется ваша проблема;
+  * размер бандла, связанное с этим время скачивания
+- если вы работали в итерационном процессе оптимизации, расскажите как вы построили фидбек-луп;
+  * речь шла больше о технической стороне самой реализации и изменению загрузчика, проверяя функционал с помощью автоматизированных тестов
+- если пользовались профайлерами - опишите находки, которые сделали с их помощью;
+  * панель разработчика в браузере + панели мониторинга после загрузки в тестовое окружение и "выше". не было подключено эффективное сжатие при передаче (настройка CDN), переход на Brotli усилил эффект еще больше.
+- расскажите, как защитили достигнутый прогресс от деградации;
+  * автоматизированные тесты
+- прикиньте, сколько денег сэкономила ваша оптимизация
+  * можно судить по нагрузке на CDN, она снизилась в 2-3 раза по объему отдаваемого трафика. размер бандла был уменьшен на примерно 600кб. при этом стал загружаться только один пакет переводов, а не все языки по умолчанию (такие библиотеки как date-fns этим грешат по умолчанию). бандл был далее оптимизирован и разбит на части, отвечающие ролям пользователям и их активным локалям.
+- если вы сделали много оптимизаций, расскажите о всех
+  * дополнительно другой отдел фронтэнд платформы смог закончить настройку и активацию экспериментальной функции webpack для lazy loading.
+  * Для архитектуры Apple M1 первый билд снизился со 176 сек до 25; Перекомпиляция снизилась с 10-13 секунд до 1-3. Это наибольший эффект за долгое время в плане улучшения пользовательского опыта для локальной разработки.
+  * в моих личных планах подключение недостающих профилировщиков в проект для локальной разработки и обновление тех инструментов, которые пересекаются с предложенными в рамках курса. в частности я заметил, что нет удобного инструмента pghero и Rails panel, а rack mini profiler отключен по умолчанию в UI. воспользовавшись pghero, сразу нашлись 54 продублированных индекса в БД. Т.е. единичные индексы, которые уже проиндексированы в рамках скомбинированных с другими полями.
+  * большой потенциал ускорения тестов, несмотря на использование test-prof применение let_it_be и before_all ограничено. И, конечно, есть большие и неэффективные фабрики. в запасе так же есть гипотеза оптимизации PostgreSQL в плане отключения Write Ahead Log при выполнении тестов.