Я не шукав рятівних проєктів. Вони знайшли мене самі — три фаундери за 18 місяців, кожен з однією й тією самою історією: «Ми найняли когось дешевого, не спрацювало, тепер потрібно полагодити».
Цей пост — не про те, щоб соромити дешевих розробників. Він про те, щоб зробити математику видимою. У кожного врятованого проєкту був паперовий слід: початкова ціна, витрачені години, вартість переробки. Коли ви ставите цифри поруч, «економія» зникає.
Усі три проєкти анонімізовані. Цифри реальні.
Проєкт 1: інтернет-магазин, що не витримував 50 замовлень
Початковий скоуп: Кастомний сторфронт у стилі Shopify для нішевого продуктового бренду. Каталог товарів, кошик, Stripe-чекаут, панель управління замовленнями.
Початковий розробник: Фрілансер із маркетплейсу. €3,500 фіксована ціна. Здав за 6 тижнів.
Що пішло не так:
Сайт виглядав нормально з 5 товарами. При 50 товарах сторінка каталогу вантажилася 11 секунд — розробник завантажував усі товари з усіма зображеннями при кожному запиті, без пагінації, без кешування. Кошик використовував localStorage без серверної валідації, тож покупці могли змінювати ціни, редагуючи сховище браузера. Stripe-інтеграція була лише в тест-моді — розробник ніколи не перемикав на продакшн і не знав, як обробляти вебхуки.
Що я знайшов на аудиті (8 годин, €640):
- Немає серверної валідації кошика — ціни були лише на клієнті
- Stripe webhooks не реалізовані — підтвердження замовлення залежало від редиректу, який ламається, якщо користувач закриває вкладку
- Немає індексів у базі даних — 50 товарів, але запити сканували всю таблицю
- Немає оптимізації зображень — 4MB фото товарів віддавалися як є
- Адмін-панель — один React-компонент на 2,000 рядків
- Немає моніторингу помилок, немає логування, немає способу дізнатися, коли щось ламається
Переробка (62 години, €4,960):
Я не став патчити. Проблема безпеки кошика та відсутність обробки вебхуків означали, що платіжний флоу був фундаментально зламаний. Я перезібрав сторфронт на Next.js із коректним серверним управлінням кошиком, Stripe webhooks, оптимізацією зображень та пагінацією.
Підсумкова вартість для фаундера:
| Стаття | Вартість |
|---|---|
| Початковий розробник | €3,500 |
| 3 місяці втрачених продажів (зламаний чекаут) | ~€8,000 (оцінка фаундера) |
| Мій аудит | €640 |
| Моя переробка | €4,960 |
| Загалом | ~€17,100 |
Нормальна збірка з нуля обійшлася б у €7K–€9K. «Дешевий» варіант коштував майже вдвічі — плюс 3 місяці зламаного магазину.
Проєкт 2: SaaS, що витік клієнтські дані
Початковий скоуп: Мультитенантний SaaS для консалтингової фірми. Клієнтський портал, завантаження документів, управління командою, базова звітність.
Початковий розробник: Племінник друга, який «знає React». €2,000 сплачено неформально за 4 місяці.
Що пішло не так:
Мультитенантності не було. Кожен користувач міг бачити дані кожного іншого користувача, просто змінивши ID в URL. Розробник зібрав одно-користувацький застосунок і припустив, що «права додамо потім». Завантажені документи йшли в публічний S3-бакет — будь-хто з URL міг отримати доступ до будь-якого файлу. Паролі зберігалися у відкритому вигляді в базі даних.
Фаундер дізнався про це, коли клієнт зателефонував і сказав: «Я бачу чужі документи».
Що я знайшов на аудиті (6 годин, €480):
- Немає middleware авторизації — кожен API-роут був публічно доступний
- Паролі у відкритому вигляді (не хешовані, навіть не солені)
- S3-бакет із публічним читанням — кожен завантажений документ доступний за URL
- Немає санітизації вводу — SQL-ін'єкція можлива на пошуковому ендпоінті
- Немає примусового HTTPS на API
- React-застосунок — ejected
create-react-appз 847 npm-вразливостями
Переробка (78 годин, €6,240):
Це була екстрена ситуація з безпекою. Я негайно зняв сайт, повідомив фаундера про витік даних і перезібрав із нуля. Next.js із коректною авторизацією (Auth.js), row-level security в Postgres, приватний S3 із підписаними URL, валідація вводу на кожному ендпоінті.
Підсумкова вартість для фаундера:
| Стаття | Вартість |
|---|---|
| Початковий розробник | €2,000 |
| 2 тижні простою при переробці | ~€4,000 (втрачений білінг клієнтів) |
| Юридична консультація щодо витоку даних | €1,200 |
| Мій аудит | €480 |
| Моя переробка | €6,240 |
| Загалом | ~€13,920 |
Нормальна збірка: €8K–€11K. «Дешевий» варіант обійшовся дорожче, розкрив клієнтські дані й ледь не вбив відносини з найбільшим акаунтом.
Проєкт 3: мобільний застосунок, що не пройшов рев'ю в App Store
Початковий скоуп: React Native застосунок-компаньйон для заходів. Показ квитків, QR-коди, пуш-сповіщення, календар заходів.
Початковий розробник: Агентство з країни з низькою вартістю. €5,000. Здали «робочий» білд за 10 тижнів.
Що пішло не так:
Застосунок працював у симуляторі, але падав на реальних пристроях. Розробник ніколи не тестував на фізичному обладнанні. Пуш-сповіщення були захардкоджені на один токен пристрою (телефон розробника). QR-код був статичною картинкою, вбудованою в бандл застосунку — він не підтягував реальні дані квитків.
Apple відхилив застосунок тричі: раз за падіння при запуску (відсутні entitlements), раз за плейсхолдер-контент (розробник залишив «Lorem ipsum» на екрані налаштувань), і раз за невідповідність функціоналу опису (QR-коди не працювали).
Після трьох відхилень за 6 тижнів фаундер прийшов до мене.
Що я знайшов на аудиті (4 години, €320):
- Застосунок падав на iOS 17 — розробник збирав лише під iOS 16
- Реалізація пуш-сповіщень неробоча — один захардкоджений токен
- QR-код — статичний PNG, не згенерований із даних квитка
- Немає API-викликів — усі дані були захардкодженим JSON у бандлі застосунку
- Expo на 3 мажорні версії відставав із відомими критичними багами
- Немає CI/CD — білди робилися вручну на машині розробника
Переробка (54 години, €4,320):
Я перезібрав застосунок із нуля на поточному Expo. Реальна API-інтеграція, реальні пуш-сповіщення через Expo Notifications, динамічні QR-коди, коректне офлайн-сховище. Пройшов рев'ю App Store з першої подачі.
Підсумкова вартість для фаундера:
| Стаття | Вартість |
|---|---|
| Початкове агентство | €5,000 |
| 4 місяці затримки (пропущений сезон заходів) | ~€12,000 (оцінка фаундера по втраченій виручці від квитків) |
| Мій аудит | €320 |
| Моя переробка | €4,320 |
| Загалом | ~€21,640 |
Нормальна збірка: €6K–€8K. «Економія» агентства в €5K коштувала фаундеру цілого сезону запуску.
Патерн
Усі три проєкти мають однаковий режим відмови:
- Низька ціна приваблює фаундера. Ціна звучить розумно, бо фаундер не знає, що означає «розумно» для софту.
- Розробник здає щось, що виглядає робочим. Демо в браузері, скріншоти в Slack, посилання на стейджинг, що вантажиться. Поверхня виглядає нормально.
- Невидима робота відсутня. Безпека, обробка помилок, продакшн-конфігурація, крайні випадки, тестування. Усе, що відділяє демо від продукту.
- Фаундер виявляє проблеми в продакшні. Зазвичай через скаргу клієнта, інцидент безпеки або відхилення App Store.
- Переробка коштує дорожче, ніж зробити правильно з першого разу. Бо тепер є терміновість, втрачена виручка та накладні витрати на аудит того, що є, перш ніж збирати те, що має бути.
Як цього уникнути
Я написав детальний чекліст червоних прапорців для перевірки розробників. Коротка версія:
Просіть продакшн-референси. Не скріншоти портфоліо — URL живих проєктів, що обробляють реальні транзакції, обслуговують реальних користувачів. Якщо розробник ніколи не випускав у продакшн, він пропустить усе, що проявляється лише в продакшні.
Питайте «що буде, якщо». «Що буде, якщо платіж не пройде?» «Що буде, якщо два користувачі редагують один запис?» «Що буде, якщо API впаде?» Розробник, який думав про сценарії відмови, відповість одразу. Той, хто не думав, скаже «розберемося потім».
Оплатіть фазу специфікації окремо. Хороша специфікація перед розробкою коштує €500–€1,000 і показує, чи розуміє розробник вашу проблему. Якщо специфікація розмита — код буде таким самим.
Просіть розклад, а не загальну суму. Якщо розробник не може сказати, скільки годин іде на авторизацію vs. основний функціонал vs. тестування — він не скоупив проєкт. Він вгадує. Ось як виглядає реальний розклад.
Якщо у вас проєкт, що зламаний, недороблений або застряг — я роблю рятівні збірки. Давайте подивимось, що у вас є і що потрібно, щоб полагодити. Аудит зазвичай займає 4–8 годин і показує, чи варто патчити або перезбирати.