{"id":14275,"url":"\/distributions\/14275\/click?bit=1&hash=bccbaeb320d3784aa2d1badbee38ca8d11406e8938daaca7e74be177682eb28b","title":"\u041d\u0430 \u0447\u0451\u043c \u0437\u0430\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0444\u0435\u0441\u0441\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0434\u0430\u0432\u0446\u044b \u0430\u0432\u0442\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"f72066c6-8459-501b-aea6-770cd3ac60a6"}

Марафон кейсов Evrone — День 25. Quiv — конвертируем знания в помощь благотворительным фондам

Расскажем суть сразу: чтобы превратить знания в помощь, нужен обменный пункт. Им стал сервис Quiv (и его русская версия — Правильно.ру). Эти сервисы помогают тем, кто ищет экспертные знания. Люди платят за общение с нужными им специалистами, а деньги уходят не эксперту, а в благотворительный фонд.

С одной стороны довольны те, кто ищет информацию. Здесь можно заплатить за крутой совет от директора по продукту Verizon Маниша Шармы, например. C другой, любой эксперт может зарегистрироваться и привлечь внимание к нуждам конкретного фонда, помочь им, потратив немного своего времени.

Quiv предлагает три вида консультаций: один письменный вопрос (ответ в течение 3 дней), чат (переписываться можно не дольше 3 дней) и телефонный звонок (15 минут).

Чтобы быстро запустить такой продукт, часть функционала мы реализовали с помощью сторонних интеграций. Это отлично сработало с платежами, например.

Дело в том, что у всех фондов в мире разные правила приёма пожертвований. Чтобы не заморачиваться с чеками и банковскими переводами, мы подключили Stripe для США и Cloud Payments для России. Также в оба сервиса добавили автоматическую пересылку данных в бухгалтерские службы.

Все сторонние продукты подключены на бэкенде. Для его разработки мы выбрали Ruby и Ruby on Rails. Инфраструктурно проект работает на Amazon Services. Всё ради отличной отказоустойчивости и отличного уровня SLA. А ещё за счёт этого мы сэкономили на DevOps.

Почему мы выбрали сторонние интеграции? Потому что каждая из них тянет на отдельный продукт. А обычно на это нет ни времени, ни ресурсов. Опять же, если вы можете быстрее запустить свой продукт с интеграцией, а потом итеративно допилить собственный функционал, лучше так и сделать.

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

В полной версии кейса на сайте мы рассказываем больше технических деталей, например про подключение поиска по сайту или телефонии.

0
Комментарии
-3 комментариев
Раскрывать всегда