Фінансова компанія · B2B SaaS · 2025
Zoho Migration — фінансовий калькулятор за 8 днів замість 4-6 місяців
Як замінили дорогий Zoho Creator на власне рішення на Cloudflare Workers + Postgres із нативною PDF-генерацією і безлімітним масштабуванням.
// Контекст
Замовник — фінансова компанія, що надає послуги корпоративним клієнтам. Команда 25 людей, 30+ корпоративних клієнтів, складні мультивалютні розрахунки.
Серце операційки — фінансовий калькулятор: вхід (умови, ставки, графіки платежів), вихід — структуровані PDF-звіти для клієнта. Калькулятор побудовано на Zoho Creator 4 роки тому — швидко, no-code, працювало.
// Що боліло
- Дорого: Zoho One Enterprise = 35€/user/міс × 25 = 875€/міс, плюс додатки і external PDF-сервіс = ~3,500€/міс на ліцензії.
- Повільно: при 1000+ розрахунків у місяць UI «вічно крутився», експорт PDF займав 8-15 секунд.
- Масштабування non-trivial: щоб додати 5 нових юзерів — додаткова ліцензія + узгодження. Платформа завжди ставала bottleneck.
- Vendor lock-in: Deluge-скрипти не переносилися. Дані можна експортувати, логіку — ні.
// Чому не «звичайна команда розробників»
Замовник зробив тендер. Дві команди оцінили проєкт у 4-6 місяців і ~25-30K€. Поки тендер тривав, я запропонував альтернативний підхід: один інженер + Claude Code.
Логіка: міграція — задача добре документована (legacy скрипти, типи даних, очікувана поведінка). Це ідеальний кейс для AI-кодинга, де велика частина — переписування формул і UI з відомими вхідними/вихідними даними.
Результат — у 5× швидше і у 3× дешевше.
// Solution — що зробили
1. Reverse engineering legacy
Експортували всі Zoho Deluge-скрипти (це їхній proprietary scripting language). Інтерв'ю з фінансовим директором — година по кожному з 8 типів розрахунків. Сформували regression-тести: 240 сценаріїв з очікуваними виходами.
2. Backend на Cloudflare Workers
Hono.js framework, TypeScript. Кожна формула — окрема функція з типізованим контрактом. Postgres на Supabase для зберігання договорів і історії розрахунків. Row-Level Security забезпечує мультитенантність.
3. Нативна PDF-генерація
Cloudflare Browser Rendering API — рендерить PDF з HTML/CSS у Worker. Безкоштовно до 100K викликів/міс. Швидкість — <2 секунди на PDF замість 8-15 у Zoho.
4. Frontend на Astro
Сторінки з статичним SSR (швидко, SEO-friendly), reactive forms через React islands. Дизайн зробили з урахуванням frequent users — keyboard shortcuts, autosave, history.
5. Auth & SSO
Clerk для управління користувачами, SSO інтеграція з корпоративним Microsoft 365. Користувач заходить через корпоративний акаунт — без додаткових паролів.
6. Stack
| Layer | Інструменти |
|---|---|
| Backend | Cloudflare Workers + Hono + TypeScript |
| Database | Supabase (Postgres) + Row-Level Security |
| Frontend | Astro 6 + React islands + Tailwind v4 |
| PDF generation | Cloudflare Browser Rendering API (нативно) |
| Auth | Clerk + Microsoft 365 SSO |
| AI assist | Claude Code (Sonnet 4.6) для всього кодинга |
// Timeline
Експорт Zoho Deluge-скриптів, інтерв'ю з фінансовим директором, mapping формул, набір regression-тестів (240 сценаріїв)
Cloudflare Worker з основними API, схема Postgres, підключення Supabase, перші 50 тестів проходять
Нативна PDF-генерація, реалізація всіх формул фінансового калькулятора, 240/240 тестів зеленого кольору
Astro frontend з реактивними формами, Clerk auth, SSO з Microsoft 365, production deploy на Cloudflare
// Result — цифри
| Метрика | Zoho (до) | Cloudflare (після) |
|---|---|---|
| Місячний cost | ~3,500 € | ~30 € |
| PDF generation | 8-15 сек | <2 сек |
| Масштабування | Per-user pricing | Безлімітне |
| Час міграції | 4-6 міс (оцінка) | 8 робочих днів |
| Regression-тести | 0 | 240/240 ✓ |
| Окупність | — | ~3 місяці |
// Що пішло не так — lessons learned
Legacy edge cases. 18 з 240 тестів спочатку «червоніли» — формули в Zoho мали недокументовану поведінку при крайніх значеннях (нульові ставки, від'ємні штрафи). Reverse engineering зайняв на 1 день довше, ніж планував.
SSO налаштування з Microsoft 365. Сам Clerk простий, але корпоративний AD має свої квирки. Витратили півдня на conditional access policy.
Postgres connection pooling. Cloudflare Workers працює у edge, а Supabase у us-east. Перші тести показали +200ms latency. Перейшли на Hyperdrive (Cloudflare service для caching connections) — latency впала до 30ms.
// FAQ
Чому замовник хотів піти з Zoho Creator? +
Три причини. Перша — per-user pricing: для команди 25+ людей платіжна модель ставала нерентабельною (~3,500€/міс тільки за ліцензії). Друга — обмеження PDF-генерації: безкоштовний слот 1000 PDF/міс закінчувався, далі — зовнішній сервіс ще ~50€/міс. Третя — повільний UI: «вічне завантаження» при роботі з великими таблицями розрахунків.
Чому Claude Code, а не звичайна команда розробників? +
Команда (3 розробники + lead) оцінила міграцію у 4-6 місяців і ~25-30K€ фікс-ставкою. З Claude Code один інженер виконав міграцію за 8 робочих днів — бо AI генерував і код, і тести, і документацію паралельно. Замовник заплатив 9K€ замість 25K€ за ту саму функціональність.
Як зберегли логіку legacy формул? +
Reverse engineering. Експортували всі Zoho Deluge-скрипти, описали кожну формулу інтерв'ю з фінансовим директором (хто пам'ятав edge cases). Згенерували набір regression-тестів — 240 сценаріїв з очікуваними виходами. Нова реалізація мала пройти всі 240 перш ніж фічу прийняли.
Що робити, якщо легасі-логіка не задокументована? +
Якщо немає тестів і немає документації — ризик максимальний. Раджу не мігрувати «у лоб», а спочатку обгорнути legacy у regression-тести (через UI-automation чи API), і тільки потім переписувати. У SmileClinic я цьому навчився: 5 днів на аудит окупились двома тижнями збереженого часу на debug.
Скільки коштує підтримка нового рішення? +
Cloudflare Workers: ~5€/міс для базового workload. Postgres на Supabase: 25€/міс. Total infra cost — ~30€/міс для всіх 25 користувачів. Проти 3,500€/міс на Zoho — економія ~42K€/рік.
Автор кейсу
Андрій Мар'ясов
AI-консультант, засновник Auspex (CRM-автоматизація) та Grow2.ai (AI-агенти + community). Будую AI- та автоматизаційну стратегію для власників і команд; впровадження веду через власні бренди. 6+ років із системами автоматизації, 3 з них — фінтех (Zoho, Salesforce, кастомні рішення).
// Інші кейси
// Висновок
Головне рішення тут було стратегічне, а не технічне: побачити, що міграція — це добре документована задача (legacy-скрипти + відомі вхідні/вихідні дані), і саме тому ідеальний кейс для AI-кодинга. Правильна постановка дала 5× швидкість і 3× економію — не сам інструмент.
Реалізовано через Auspex — CRM-автоматизація та міграція бізнес-процесів. Стратегію я будую особисто; саме впровадження веде команда Auspex.
У вас теж legacy, з якого пора йти?
Почнемо з розмови: чи варто мігрувати взагалі, де ризики й де важіль. Стратегію будуємо разом, впровадження — через Auspex.
Особистий advisory →