У сучасних стартап-пітчдеках з’явилася нова амбіція: «Ми, по суті, Palantir, але для X».
Засновники розповідають про інтеграцію forward-deployed інженерів (FDE) у команди клієнтів, розробку глибоко кастомізованих робочих процесів і роботу в режимі спецпідрозділу, а не традиційної софтверної компанії. Кількість вакансій для «forward-deployed engineers» зросла на сотні відсотків цього року, оскільки компанії переймають модель, яку Palantir започаткував на початку 2010-х.
Я розумію, чому це здається привабливим. Бізнес-клієнти дійсно розгублені перед вибором технічних продуктів; усе зараз просувається як AI, і ще ніколи не було так складно відрізнити справді цінне від інформаційного шуму. Пітч Palantir — десантувати невелику команду у складне середовище, з’єднати розрізнені системи і за кілька місяців впровадити кастомізовану платформу — переконливий. Для стартапу, який прагне укласти перші семизначні контракти, обіцянка «ми відправимо до вас інженерів і все запустимо» — дуже сильна.
Але я скептично ставлюся до того, що «палантиризація» може масштабуватися як універсальне рішення. Palantir — це «категорія одна» (достатньо подивитися на динаміку її акцій!), і більшість компаній, які копіюють цю модель, приречені стати дорогими сервісними бізнесами з софтверною оцінкою та без стійкої конкурентної переваги. Це нагадує, як у 2010-х кожен стартап називав себе «платформою», хоча справжніх платформних компаній дуже мало саме через складність їх побудови!
Ця стаття — спроба відокремити те, що справді масштабоване у моделі Palantir, від унікальних рис — і запропонувати більш прагматичний план для засновників, які хочуть поєднати корпоративне програмне забезпечення з високим рівнем сервісу.
Що насправді означає «палантиризація»
Під «палантиризацією» розуміють декілька взаємопов’язаних підходів:
Forward-deployed, embedded engineering
Forward-deployed інженери («Deltas» і «Echoes» у внутрішній термінології Palantir) місяцями працюють у команді клієнта, щоб глибоко зрозуміти специфіку, інтегрувати системи та створити кастомні процеси поверх Foundry (або Gotham у випадку підвищених вимог до безпеки). Оскільки ціна фіксована, класичних «SKU» тут немає. Інженери відповідають за створення та підтримку цих рішень.
Highly opinionated, integrated platform
Під капотом продукти Palantir — це не набір окремих компонентів. Це цілісні платформи для інтеграції даних, управління та операційної аналітики, що більше схожі на операційну систему для даних організації. Мета — перетворити фрагментовані дані на рішення в реальному часі з високою довірою до результату.
Upmarket, high-touch GTM
«Палантиризація» також описує стиль виходу на ринок: довгі, інтенсивні цикли продажів у критично важливі середовища (наприклад, оборона, поліція, розвідка). Регуляторна складність і масштаб «ставок» у цих сферах — це радше перевага, ніж недолік.
Outcomes, not licenses
Дохід формується багаторічними контрактами, орієнтованими на досягнення результату, де поєднуються програмне забезпечення, послуги і постійна оптимізація. Окремі контракти можуть сягати десятків мільйонів доларів на рік.
Нещодавній аналіз Palantir відзначає її як «категорію одну», оскільки компанія одночасно успішна у: (a) створенні інтегрованих продуктових платформ, (b) впровадженні елітних інженерів у операційні процеси клієнтів, (c) доведенні ефективності в критично важливих державних і оборонних проєктах. Більшість компаній здатні опанувати лише одну або дві складові — не всі три водночас.
Проте у 2025 році всі хочуть використати «ауру» цієї моделі.
Чому всі зараз хочуть копіювати Palantir
Три ключові фактори сходяться в одному місці:
1. Корпоративний AI має проблему впровадження.
Багато AI-проєктів усе ще зупиняються до того, як потрапляють у продуктивне середовище, часто через неякісні дані, складність інтеграції та відсутність власника процесу всередині компанії. Попит на купівлю AI з боку керівництва високий, але для реального впровадження і повернення інвестицій часто потрібен тісний супровід.
2. Forward-deployed інженери виглядають як відсутня ланка.
Дані й огляди вакансій свідчать про вибуховий ріст FDE — на 800–1000% цього року залежно від джерела — оскільки AI-стартапи впроваджують інженерів для забезпечення реального результату впровадження.
3. Швидке масштабування стало нормою (і легше зростати з контрактами на 7 цифр, ніж на 5!)
Якщо відрядження інженерів — це шлях підписати контракт на $1M+ із Fortune 500 чи державною агенцією, багато молодих компаній погоджуються пожертвувати маржею заради динаміки зростання. Інвестори також все частіше погоджуються на субоптимальні валові маржі, адже нові AI-рішення з великим обсягом інференсу цього вимагають. Розрахунок у тому, що ви завоюєте довіру клієнта для доставки результату і зможете відповідно сформувати ціну.
Отже, формується наратив: «Ми зробимо, як Palantir. Надішлемо невелику елітну команду, створимо щось унікальне, і з часом це стане платформою».
Цей підхід може спрацювати лише за дуже специфічних умов. Але є жорсткі обмеження, які засновники часто ігнорують.
Де аналогія не працює
Спроба продавати результати з першого дня
Флагманський продукт Palantir, Foundry, — це комбінація сотень мікросервісів, які спрямовані на досягнення результату. Це продуктовані й ідейні підходи до типових проблем у кожній галузі. Поспілкувавшись із сотнями засновників AI-стартапів за останні два роки, я можу сказати, де їхня аналогія ламається: стартапи пропонують набір амбітних цілей за результатом, тоді як Palantir створював цілеспрямовані мікросервіси як фундамент своїх можливостей. Саме це відрізняє Palantir від консалтингових компаній (і сприяє тому, що вона оцінюється у 77x прогнозної виручки).
Palantir Gotham — це платформа для оборони та розвідки, яка допомагає військовим, розвідувальним і правоохоронним органам інтегрувати й аналізувати різнорідні дані для планування й розслідувань.
Palantir Apollo — це платформа для розгортання й управління ПЗ, яка автономно й безпечно доставляє оновлення та нові функції у будь-яке середовище, включно з мультихмарними, локальними та ізольованими системами.
Palantir Foundry — це міжгалузева платформа для операцій з даними, що інтегрує дані, моделі й аналітику для підтримки оперативних рішень у компаніях.
Palantir Ontology — це динамічна цифрова модель організації, що відображає реальні сутності, зв’язки й логіку, забезпечуючи роботу додатків та ухвалення рішень у Foundry.
Palantir AIP (Artificial Intelligence Platform) пов’язує AI-моделі, зокрема Large Language Models (LLMs), із даними та операціями організації через Ontology для створення готових до продуктивного використання AI-процесів і агентів.
Як зазначено у нещодавньому звіті Everest: «Контракти Palantir стартують з малого. Перше залучення може охоплювати короткий bootcamp та обмежені ліцензії. Якщо цінність доведено, додаються нові кейси, процеси й домени даних. З часом структура доходу зміщується у бік підписки на ПЗ, а не сервісів. На відміну від консалтингу, сервіси у Palantir — це засіб впровадження продукту, а не основне джерело доходу. На відміну від більшості софтверних компаній, Palantir готовий фінансувати власний інженерний час наперед, щоб залучити значимого клієнта».
AI-компанії, які я спостерігаю зараз, часто можуть відразу підписувати семизначні контракти. Але це здебільшого тому, що вони повністю займаються кастомізацією — вирішують будь-які проблеми перших клієнтів, сподіваючись згодом знайти спільні риси для побудови основних можливостей або SKU.
Не кожна проблема — «рівня Palantir»
Перші впровадження Palantir відбувалися у сферах, де інакше «нічого не працює»: контртероризм, виявлення шахрайства, логістика, критичні медичні операції. Вартість вирішення таких проблем вимірювалася мільярдами доларів, врятованими життями або геополітичними наслідками, а не приростом ефективності.
Якщо ви продаєте SaaS-компанії оптимізацію sales-процесів на 8%, ви не можете дозволити собі такий рівень кастомізації. ROI просто не виправдовує місяці onsite-інженерії.
Більшість клієнтів не хоче бути вашою R&D-лабораторією назавжди
Клієнти Palantir фактично погоджуються спільно розвивати продукт; вони терплять багато, бо ставки високі, а альтернатив мало.
Більшість компаній, особливо поза оборонною й регульованою сферами, не хочуть бути довготривалим консалтинговим проєктом. Їм потрібні передбачувані впровадження, сумісність із існуючим ПЗ і швидка цінність.
Щільність і культура талантів не масштабується
Palantir понад десятиліття відбирає і навчає унікально сильних універсальних інженерів, які однаково впевнено пишуть код, працюють із бюрократією й спілкуються з воєначальниками, CIO та регуляторами. Випускники Palantir сформували цілу «мафію» серед фаундерів і операційних лідерів. Багато з них — унікальні, бо одночасно технічні й ефективні у співпраці з клієнтами.
Більшість стартапів не можуть розраховувати, що наберуть сотні таких людей. На практиці «зберемо команду FDE у стилі Palantir» часто перетворюється на:
- Pre-sales solution інженерів із новою назвою «FDE»
- Молодих універсалів, які одночасно виконують ролі продукту, впровадження й аккаунт-менеджменту
- Керівників, які ніколи не бачили Palantir у роботі, але їм подобається концепція
Безумовно, існує безліч талановитих людей, і можливості писати код стають доступними навіть для нетехнічних співробітників завдяки рішенню Cursor. Але щоб масштабувати модель Palantir, потрібне унікальне поєднання бізнес- і технічних навичок, і досвід роботи саме там — дуже бажаний. Але таких мало!
Пастка сервісної моделі — реальна
Palantir працює, тому що під кастомізацією є справжня платформа. Досвідчені спостерігачі зазначають: якщо копіювати лише аспект із впровадженими інженерами, отримаєте тисячі унікальних проєктів, які неможливо супроводжувати чи оновлювати. Навіть якщо AI дозволяє досягти софтверної валової маржі, компанії, які занадто захоплюються forward deployment без потужної продуктової основи, не зможуть побудувати масштабовану бізнес-модель і довготривалі бар’єри. Недосвідчений інвестор може побачити стрімке зростання контрактів із великими корпораціями й захотіти долучитися. Проте питання — що буде, коли десятки чи сотні таких стартапів із $10M контрактами почнуть конкурувати з однаковими пропозиціями?
На цьому етапі ви вже не «Palantir для X». Ви — «Accenture для X» із симпатичнішим інтерфейсом.
Що Palantir зробив по-іншому
Якщо відкинути міфологію, є кілька аспектів, які варто ретельно вивчити:
1. Платформа-спочатку, а не проєкт-спочатку
Команди forward-deployed Palantir працюють на основі невеликого набору багаторазових примітивів (моделі даних, контроль доступу, рушії процесів, компоненти візуалізації), а не пишуть індивідуальні системи для кожного клієнта.
2. Чітке бачення того, як має відбуватись робота
Компанія не просто автоматизує існуючі процеси; вона часто змінює підходи клієнта, закладаючи їх у програмний продукт. Це рідкісна сміливість для вендора й основа для повторного використання.
3. Довга перспектива і капітал
Бути схожим на Palantir означає пережити періоди негативного ставлення, політичних суперечок і неочевидної монетизації, поки платформа та вихід на ринок дозрівають.
4. Дуже специфічний ринковий мікс
Ранній фокус на розвідці та обороні — це перевага: висока готовність платити, високі витрати на зміну, великі ставки і невелика кількість дуже великих клієнтів. Плюс старі гравці, які десятиліттями майже не мали конкуренції.
Інакше кажучи, Palantir — це не просто «софтверна компанія + консалтинг». Це «софтверна компанія + консалтинг + політичний проєкт + дуже терплявий капітал».
Цього не можна просто додати до вертикального SaaS-продукту й очікувати масштабування.
Більш реалістична рамка: коли «палантиризація» має сенс?
Замість питання «Як бути схожими на Palantir?» краще поставити низку фільтруючих питань:
1. Критичність проблеми
- Чи ця проблема критично важлива (життя, нацбезпека, мільярди доларів) чи лише «приємна» (10–20% ефективності)?
- Чим вищі ставки, тим більше виправдана forward-deployed модель.
2. Концентрація клієнтів
- Ви продаєте десяткам великих чи тисячам малих клієнтів?
- Впроваджена інженерія краще масштабується за умови концентрованої бази з високим ACV.
3. Фрагментованість домену
- Чи клієнти мають подібні процеси й інструменти, чи кожне впровадження унікальне?
- Якщо кожен клієнт — «сніжинка», створити єдину платформу складно. Дещо спільного допомагає.
4. Регуляторика і «гравітація» даних
- Ви працюєте у регульованих сферах із великими проблемами інтеграції даних (оборона, медицина, фінансові злочини, критична інфраструктура)?
- Саме тут інтеграційна робота у стилі Palantir найбільш цінна.
Якщо ви здебільшого у «лівому нижньому куті» цих вимірів (низька критичність, фрагментовані клієнти, проста інтеграція), повна «палантиризація» майже напевно не ваш шлях. У таких випадках краще підходить bottoms-up, PLG.
Що варто переймати
Незважаючи на скепсис щодо універсальності моделі Palantir, деякі елементи підходу заслуговують уваги.
1. Сприймайте forward deployment як риштування, а не основну конструкцію
Цілком доцільно:
- Впроваджувати інженерів із першими дизайн-партнерами
- Зробити все, щоб перші 3–5 клієнтів отримали робоче рішення
- Використати ці кейси для перевірки примітивів і абстракцій
Але це потребує чітких меж:
- Обмеження тривалості (наприклад, «90-денний спринт до продакшену»)
- Чіткі співвідношення (наприклад, максимум інженерів на $1M ARR для одного клієнта)
- Мета — кожного кварталу перетворювати bespoke-код на конфігурації або шаблони
Інакше «зробимо продукт пізніше» перетворюється на «так і не зробили».
2. Створюйте на основі сильних примітивів, а не кастомних процесів
Головний урок Palantir — у продуктовій архітектурі:
- Уніфікована модель даних і рівень доступу
- Єдиний рушій процесів і UI-примітиви
- Конфігурація замість коду там, де це можливо
Forward-deployed-команди мають обирати і перевіряти, які примітиви збирати, а не створювати нові для кожного клієнта. Нові розробки — для інженерів.
3. Включайте FDE у продукт, а не лише у впровадження
У Palantir forward-deployed інженери активно беруть участь у відкритті й ітерації продукту, а не тільки у впровадженні. Сильні продуктові й платформні команди отримують цінний фідбек із «передової».
Якщо FDE відокремлені в підрозділ «послуг», цей зворотний зв’язок втрачається, і бізнес дрейфує у сервісну модель.
4. Будьте чесними щодо структури маржі
Якщо ви декларуєте 80%+ валову маржу ПЗ і 150% net dollar retention, але ваша модель потребує тривалих onsite-проєктів, будьте відверті — хоча б внутрішньо — щодо компромісів.
Для деяких сегментів структурно нижча маржа й більший ACV — це раціонально. Проблема — видавати себе за SaaS, коли насправді ви сервіс із платформою. Інвестори шукають шлях до максимального валового прибутку, і один варіант — масштабніші контракти з більшими COGS.
Як я би перевіряв «палантиризований» стартап
Коли я зустрічаю засновника, який заявляє: «ми як Palantir для X», мої питання виглядають так:
1. Покажіть чітку межу продуктової платформи.
Де закінчується спільний продукт і починається клієнтський код? Як швидко змінюється ця межа?
2. Проведіть по таймлайну впровадження.
Скільки людино-місяців від підписання до продуктивного використання? Що обов’язково має бути кастомним?
3. Якою буде маржа на третьому році для зрілого клієнта?
Чи зменшується обсяг forward-deployed роботи з часом? Якщо ні — чому?
4. Що станеться, якщо ви підпишете 50 клієнтів наступного року?
Найм? Онбординг? Продукт? Підтримка? Хочу побачити, де модель дає збій.
5. Як ви вирішуєте не кастомізувати?
Готовність відмовлятися від кастомної роботи часто відрізняє продуктову компанію від сервісної з гарним демо.
Якщо відповіді чіткі, базуються на реальних впровадженнях і логічно вибудувані, тоді forward-deployed модель у стилі Palantir може дати перевагу.
Якщо ж відповіді розмиті, а кожен кейс унікальний, складно оцінити повторюваність і потенціал масштабування.
Висновок
Успіх Palantir створив потужну ауру у венчурному середовищі: малі команди елітних інженерів десантуються у складні системи, інтегрують хаотичні дані й будують рішення, що змінюють прийняття рішень організаціями.
Виникає спокуса думати, що кожен AI- чи data-стартап має виглядати саме так. Але для більшості категорій повна «палантиризація» — небезпечна ілюзія:
- Проблеми не досить критичні
- Клієнти надто фрагментовані
- Модель талантів не масштабується
- Економіка поступово перетворюється на сервісний бізнес
Більш корисне для засновників питання — не «Як нам стати Palantir?», а:
«Який мінімальний обсяг впровадження у стилі Palantir потрібен, щоб подолати розрив в AI-адопшені у нашій категорії — і як швидко ми зможемо побудувати справжній продуктовий бізнес?»
Якщо знайти цю межу, можна використати ключові принципи Palantir, не переймаючи те, що зашкодить.
Відмова від відповідальності:
- Ця стаття є передруком із [a16z]. Всі права належать оригінальному автору [Marc Andrusko]. Якщо є заперечення щодо передруку, звертайтеся до команди Gate Learn, і вони швидко вирішать питання.
- Відмова від відповідальності: погляди й думки, висловлені в цій статті, є виключно позицією автора і не є інвестиційною порадою.
- Переклади статті іншими мовами здійснюються командою Gate Learn. Якщо не зазначено інше, копіювання, розповсюдження чи плагіат перекладів заборонені.
