Czy warto budować firmę opartą na integracjach API?

Z drugiej strony część produktu znajduje się poza kontrolą dostawcy. Właściciel zewnętrznego systemu może zmienić API, limity zapytań, sposób autoryzacji, cennik, regulamin albo całkowicie wycofać funkcję, na której oparto usługę.

To nie jest argument przeciwko temu modelowi. Trzeba po prostu od początku budować firmę tak, jakby takie zmiany miały się wydarzyć. Bo prędzej czy później się wydarzą.

Gdzie na integracjach API rzeczywiście można zarabiać?

Samo przesłanie danych z systemu A do systemu B nie jest jeszcze szczególnie mocnym produktem.

Jeżeli program pobiera zamówienie ze sklepu i tworzy na jego podstawie fakturę, wartość nie polega na samym wywołaniu dwóch endpointów API. Klient płaci za to, że nie musi ręcznie przepisywać danych, pilnować statusów, poprawiać pomyłek i zatrudniać człowieka do wykonywania powtarzalnych czynności.

To zasadnicza różnica.

Dobra firma integracyjna sprzedaje automatyzację procesu, a API jest jedynie technologią znajdującą się pod spodem.

Przykładowo integracja sklepu z systemem księgowym może:

pobrać zamówienie, rozpoznać rodzaj klienta, wystawić odpowiedni dokument, przesłać go do KSeF, zmienić stan magazynowy, rozliczyć płatność i przekazać dane do księgowości.

Klient nie kupuje „integracji REST API”. Kupuje brak kilku godzin ręcznej pracy miesięcznie.

Im bliżej pieniędzy, sprzedaży albo istotnego procesu operacyjnego znajduje się integracja, tym zwykle większa jest gotowość do płacenia za nią.

Dlatego lepszym biznesem może być automatyzacja rozliczeń dla sklepów internetowych niż aplikacja przenosząca kontakty z jednego notesu do drugiego, nawet jeśli technicznie druga integracja jest bardziej skomplikowana.

Najbardziej niebezpieczny model: cały biznes zależy od jednej platformy

Wyobraźmy sobie SaaS, którego jedyną funkcją jest pobieranie historii wiadomości z konkretnego komunikatora i analizowanie jej dla klienta.

Firma rośnie, ma 2000 klientów i zatrudnia 15 osób.

Platforma zmienia jednak limity API. Dotychczas aplikacja mogła pobierać dużą liczbę wiadomości, a po zmianie wybrane metody mogą być wywoływane znacznie rzadziej.

W ciągu jednego dnia ekonomika produktu może przestać się zgadzać.

To nie jest hipotetyczne ryzyko. Duże platformy regularnie zmieniają zasady.

Shopify przeszedł z REST Admin API w kierunku GraphQL i dotychczasowe REST API traktuje już jako rozwiązanie legacy. Slack zmienił limity części metod związanych z historią rozmów dla aplikacji dystrybuowanych poza Marketplace. Stripe stosuje wersjonowanie, w którym większe aktualizacje mogą wprowadzać zmiany niezgodne wstecz.

Tak właśnie wygląda życie firmy integracyjnej.

Dlatego bardzo ostrożnie podchodziłbym do biznesu, w którym:

90% przychodów zależy od jednego API, a firma nie ma żadnego wpływu na jego właściciela.

Lepszy układ to produkt rozwiązujący określony problem biznesowy i obsługujący kilka źródeł danych.

Firma integrująca sprzedaż internetową nie powinna być „dodatkiem do sklepu X”. Może obsługiwać WooCommerce, Shopify, PrestaShop i kolejne platformy.

Firma integrująca księgowość może łączyć się z kilkoma programami finansowymi.

Jeśli jeden dostawca zmieni zasady, problem nadal będzie poważny, ale nie stanie się automatycznie końcem całego biznesu.

API nie jest napisane raz na zawsze

Jednym z największych błędów w kalkulacji projektu integracyjnego jest myślenie:

„Integrację zrobimy w trzy tygodnie i później będzie działała”.

Prawdopodobnie nie będzie.

Trzeba obserwować changelogi, nowe wersje API, zmiany pól, mechanizmów logowania, limitów i webhooków.

Shopify publikuje kolejne stabilne wersje API, a starsze po określonym czasie przestają być wspierane. Stripe umożliwia przypięcie integracji do konkretnej wersji, ale przejście na większą wersję może wymagać zmian w kodzie.

Oznacza to, że każda nowa integracja jest nie tylko funkcją produktu. Jest również przyszłym kosztem utrzymania.

Jeżeli firma obsługuje 3 integracje, problem jest niewielki.

Przy 50 sytuacja wygląda już inaczej.

W poniedziałek zmienia się autoryzacja jednego systemu. We wtorek drugi dostawca dodaje nową wersję API. W czwartek trzeci zaczyna zwracać nowe wartości statusów. W piątek okazuje się, że webhook czwartego systemu czasami przychodzi dwukrotnie.

Zespół, który miał tworzyć nowe funkcje, zaczyna głównie utrzymywać stare połączenia.

Dlatego liczby integracji nie powinno się traktować jako prostego KPI. „Mamy 120 integracji” brzmi efektownie, ale może oznaczać 120 elementów wymagających testowania i serwisowania.

Czasem lepiej mieć 15 naprawdę dopracowanych integracji używanych przez tysiące klientów.

Integracja musi zakładać, że API przestanie odpowiadać

Nie można projektować integracji tak, jakby zewnętrzny system był lokalną bazą danych.

API może odpowiedzieć błędem. Może działać wolniej. Może zwrócić 429 z powodu przekroczenia limitu. Dostawca może mieć awarię.

GitHub, Shopify i praktycznie każda duża platforma stosują limity zapytań. Mogą one zależeć od użytkownika, aplikacji, planu klienta, rodzaju operacji albo kosztu konkretnego zapytania.

Dlatego dobry mechanizm integracyjny nie wykonuje jednego requestu i nie zakłada, że odpowiedź zawsze przyjdzie poprawnie.

Potrzebne są kolejki, ponawianie nieudanych operacji, kontrola limitów, odpowiednie opóźnienia między próbami i monitoring.

Warto również zadbać o idempotencję.

Jeżeli system dwukrotnie otrzyma informację:

„zamówienie 12345 zostało opłacone”,

nie powinien wystawić dwóch faktur.

Podobnie jeśli odpowiedź API zaginie po drodze, program musi umieć ustalić, czy operacja rzeczywiście się nie powiodła, czy tylko nie otrzymał potwierdzenia.

Takie sytuacje praktycznie nie pojawiają się podczas pięciominutowej prezentacji dla inwestora, ale właśnie one później decydują, czy klient uważa integrację za niezawodną.

Webhook jest zwykle lepszy niż ciągłe pytanie API

Najprostsza integracja może co minutę pytać:

„Czy pojawiły się nowe zamówienia?”

Jeżeli obsługujemy 10 klientów, można tego długo nie zauważać.

Przy 10 000 kont oznacza to jednak ogromną liczbę zapytań, z których większość odpowiada: „nie”.

Jeżeli platforma udostępnia webhooki, lepiej wykorzystać model zdarzeniowy.

Sklep sam informuje:

„pojawiło się zamówienie”.

System integracyjny reaguje dopiero wtedy.

Zmniejsza to liczbę wywołań API i pozwala szybciej reagować na zdarzenia.

Webhooków również nie można jednak traktować bezkrytycznie. Zdarzenie może przyjść dwukrotnie, z opóźnieniem albo w innej kolejności niż zakładano.

Dlatego integracja powinna umieć okresowo uzgodnić swój stan ze źródłowym systemem i wykryć brakujące dane.

Autoryzacja potrafi być większym problemem niż samo API

Podczas tworzenia pierwszej wersji produktu programista często korzysta z własnego tokena API i wszystko działa.

Później przychodzi etap publicznego udostępnienia aplikacji.

I okazuje się, że trzeba przejść OAuth, skonfigurować ekran zgody, politykę prywatności, przekierowania, właściwe zakresy dostępu oraz proces weryfikacyjny platformy.

Google wymaga weryfikacji aplikacji korzystających z części wrażliwych lub ograniczonych zakresów danych. Przy najbardziej wrażliwych dostępach może być potrzebna również okresowa zewnętrzna ocena bezpieczeństwa.

Nie jest to coś, co powinno być odkrywane tydzień przed premierą.

Podobnie marketplace'y mogą mieć własny proces akceptacji aplikacji, warunki komercyjne i ograniczenia dotyczące sposobu przechowywania danych.

Przed stworzeniem integracji trzeba więc przeczytać nie tylko dokumentację endpointów, ale również:

warunki korzystania z API, zasady dystrybucji aplikacji, politykę danych, wymagania bezpieczeństwa i regulamin marketplace.

Może się okazać, że funkcja jest technicznie możliwa do wykonania, ale regulamin platformy nie pozwala jej sprzedawać w planowany sposób.

Największą przewagą może być dystrybucja

Uzależnienie od dużej platformy ma też drugą stronę.

Jeżeli aplikacja trafia do marketplace'u Shopify, Salesforce, HubSpot czy innego popularnego systemu, pojawia się dostęp do klientów, których samodzielne zdobycie byłoby kosztowne.

Użytkownik już ma problem:

„Potrzebuję połączyć system A z systemem B”.

Wchodzi więc do katalogu integracji i szuka rozwiązania.

To znacznie lepsza sytuacja niż tworzenie całkowicie nowej kategorii produktu i tłumaczenie klientowi od początku, dlaczego jej potrzebuje.

Firma integracyjna może dzięki temu rosnąć w oparciu o istniejący ekosystem.

Trzeba tylko pamiętać, że marketplace nie jest własnym kanałem sprzedaży. Platforma może zmienić algorytm wyszukiwania, zasady publikowania, prowizje albo wymagania.

Własna marka, strona, SEO, partnerzy i sprzedaż bezpośrednia nadal mają znaczenie.

Jak wyceniać integracje?

Najgorszym modelem jest często jednorazowa opłata za uruchomienie integracji i „bezpłatne utrzymanie na zawsze”.

Kod trzeba później aktualizować, a klient nic już za niego nie płaci.

Przy produkcie SaaS bardziej naturalny jest abonament.

Może być naliczany:

Każdy model ma wady.

Rozliczenie za operację dobrze skaluje przychód z użyciem produktu, ale klient może obawiać się nieprzewidywalnego rachunku.

Stały abonament jest prostszy, ale przy jednym kliencie wykonującym 200 operacji miesięcznie i drugim wykonującym 2 miliony różnica w kosztach infrastruktury i API może być ogromna.

Najczęściej dobrze sprawdzają się pakiety z określonym zakresem użycia i możliwością przejścia na wyższy plan.

Trzeba też znać koszt utrzymania integracji.

Jeżeli dana integracja generuje 5000 zł MRR, ale każdego miesiąca programiści poświęcają na nią 40 godzin, a support kolejne 20, może być znacznie mniej atrakcyjna niż integracja generująca 3000 zł i praktycznie niewymagająca obsługi.

Nie każdą integrację warto budować

Klienci często zgłaszają:

„Czy możecie zintegrować się jeszcze z programem X?”

Odpowiedź nie zawsze powinna brzmieć „tak”.

Najpierw dobrze sprawdzić:

ilu potencjalnych klientów korzysta z tego systemu, ilu rzeczywiście zapłaci za połączenie, jak wygląda dokumentacja API, czy API obejmuje potrzebne funkcje, jakie są limity, czy jest sandbox, jak działa OAuth, jak często zmieniają się wersje i kto będzie utrzymywał integrację.

Jeżeli jeden klient płacący 200 zł miesięcznie prosi o integrację wymagającą trzech tygodni pracy, biznesowo może się ona nigdy nie zwrócić.

Inaczej, gdy ten sam system ma 50 000 potencjalnych użytkowników, a połączenie może być sprzedawane wielokrotnie.

Wtedy praca wykonana raz staje się produktem.

I właśnie tu pojawia się prawdziwa przewaga skalowalnego biznesu integracyjnego.

Najlepiej, gdy integracja nie jest całym produktem

Najbardziej odporne firmy nie mówią:

„naszym produktem jest integracja X z Y”.

Mówią:

„automatyzujemy obsługę zamówień”,
„automatyzujemy księgowanie”,
„synchronizujemy stany magazynowe”,
„łączymy dane sprzedażowe”,
„automatyzujemy rozliczenia”.

Dzisiaj robią to przez API systemu X. Jutro mogą dodać system Y.

Jeżeli właściciel pierwszej platformy zamknie API, problem jest poważny, ale firma nadal posiada klientów, wiedzę o procesie, technologię i inne integracje.

Jeszcze większą przewagę daje własna warstwa danych i logiki.

Zamiast pisać osobno:

Shopify → system księgowy,
WooCommerce → system księgowy,
PrestaShop → system księgowy,

można stworzyć wewnętrzny wspólny model zamówienia.

Każdy sklep tłumaczy swoje dane na ten model. Z drugiej strony każdy program księgowy potrafi ten model odebrać.

Przy trzech sklepach i trzech systemach księgowych nie trzeba wtedy utrzymywać dziewięciu całkowicie osobnych integracji.

Powstaje warstwa pośrednia.

Tak zaprojektowany produkt dużo łatwiej rozwijać.

Kiedy taki biznes ma największy sens?

Najlepszy kandydat to proces, w którym klient dzisiaj ręcznie przenosi dane między systemami i robi to regularnie.

Jeszcze lepiej, gdy błąd kosztuje pieniądze.

Jeżeli księgowa codziennie przepisuje setki dokumentów, sklep ręcznie przenosi zamówienia do ERP albo hurtownia aktualizuje ceny w kilku kanałach sprzedaży, problem istnieje niezależnie od tego, czy ktoś stworzy integrację.

Firma nie musi wtedy przekonywać klienta, że automatyzacja jest ciekawa. Wystarczy pokazać, ile pracy może zniknąć.

Szczególnie atrakcyjne są procesy powtarzalne, wykonywane u wielu podobnych klientów.

Jedna dedykowana integracja wykonana za 50 000 zł dla jednego przedsiębiorstwa jest usługą software house'u.

Ta sama integracja sprzedawana 1000 firm po 100 zł miesięcznie staje się produktem SaaS.

Różnica technologiczna może być niewielka. Różnica biznesowa jest ogromna.

Czy warto?

Tak. Integracje API są dziś jednym z naturalnych fundamentów biznesu software'owego. Coraz więcej programów udostępnia API, firmy korzystają jednocześnie z wielu systemów, a potrzeba wymiany danych między nimi rośnie.

Nie budowałbym jednak firmy, której jedyną przewagą jest „znamy endpoint tego API”.

Dokumentację może przeczytać konkurencja. Kod połączenia również da się odtworzyć.

Trudniej skopiować kilkadziesiąt dopracowanych scenariuszy, obsługę błędów, mapowanie danych, doświadczenie z nietypowymi przypadkami, tysiące działających instalacji i produkt, który klientowi po prostu rozwiązuje cały proces.

Wtedy API przestaje być produktem.

Staje się infrastrukturą, dzięki której produkt może działać.

I właśnie taki model ma największą szansę zbudować trwałą firmę.