diff --git a/case-study.md b/case-study.md
new file mode 100644
index 0000000..f00ae76
--- /dev/null
+++ b/case-study.md
@@ -0,0 +1,70 @@
+## О проекте
+
+Я работаю в компании Jetrockets.
+
+Пишем проект для одной американской юридической компании, реализуем единое приложения удовлетворяющее  их потребностям, раньше им приходилось использовать различный софт для разных задач, теперь с нашим приложением все находится в одном месте.
+
+Проект разрабатывается с конца февраля 2020 года.
+
+Я пришел на проект да и в целом в компанию в конце января 2021, в компании являюсь back-end разработчиком на ruby.
+
+Приложение представляет собой API которое общается с отдельным фронтом написанном полностью на Svelte.
+
+Перформанском в проекте особо не занимались поскольку проект предназначен для корпоративного клиента,
+Никаких систем мониторинга не используется, разве что шлем ошибки в rollbar
+
+## Stack
+0. Rails 6
+1. Grape для написания API
+2. Dry-rb для валидаций и инициализаций 
+3. PostgreSQL
+4. Rspec
+
+## Case 1
+
+Начал оптимизировать проект с самой больной точки, это генерация отчета, его можно было посмотреть в веб версии и экспортировать в разные форматы.
+
+Проблема состояла в том что это происходило довольно медленно, особенно на моем компьютере, где стоял простой hdd,
+порой приходилось лезть на сервер где используется ssd что бы проверить как генерируется отчет.
+
+Мы это долго задумывали и как появилась возможность перевели работу в sidekiq, не знаю как, но  он стал работать в десятки раз быстрее, мне так и не удалось выяснить почему синхронно и асинхронно была такая колоссальная разница во времени, возможно держа соединение открытым на время экспорта, что-то замедляло его.
+
+## Case 1.1
+
+я решил еще больше ускорить экспорт и начал с кода, профилировал его всеми изученными инструментами и особых проблем с кодом не было, он был написан довольно хорошо я нашел парочку больных точек которые не играли особой роли в скорости формирования отчета для экспорта,
+
+тогда я решил переключиться на базу данных, начал с pgHero, он мне показал медленные запросы, но их причина не была ясна, переключился на NewRelic, благо теперь он бесплатный для одного юзера, собрал небольшую аналитику и заметил что в запросе часто используется поиск по составному полю, я добавил индекс и удалось добиться ускорения примерно на 30%
+так же я заметил что часто используется связующая таблица, сделал релоад и магическим образом это помогло добиться двухкратного ускорения экспорта.
+
+До сих пор остается актуальной проблемой то что мы при экспорте грузим все записи в ОЗУ поскольку при выборке используется сложная сортировка, а батчами такую сортировку не выполнить.
+
+
+## Case 2 
+
+Занялся тестами, тесты шли 10 минут в одном потоке, а в parallel_tests ~3 минуты.
+
+Прогнал  test-prof на наличие повторяющихся вызовов let и заменил их на let_it_be, за минимальные усилия удалось ускорить экспорт в два раза до 1.4 минуту(+1905 тестов), там еще есть много чего то можно оптимизировать но пока остановился на этом.
+
+### Итого
+
+В итоге удалось облегчить жизнь клиентам ускорил им экспорт, так и разработчикам ускорил им тесты.
+
+К сожалению проект на стадии завершения, сдаем буквально на следующей неделе и многое применить не удастся.
+
+Но как минимум коллеги оценили ускорение прогона тестов и test-prof точно станет часть проекта.
+
+### Проблемы при оптимизации
+
+Поскольку в качестве Api используется Grape то NewRelic не очень хорошо понимал что происходит в ресурсах, и на графиках выполнение Grape могло занимать 80% времени и не понятно что там внутри.
+
+let_it_be тоже следует применять осторожно поскольку он порождает нестабильные тесты, то проходят, то не проходят, у него видимо какие-то проблемы с ассоциациями которые создаются внутри фабрик.
+
+
+
+
+
+
+
+
+
+