[PRAKTYCZNA LISTA] Jak wybrać platformę nocode?

Większość konsultacji jakie przeprowadzam z ludźmi sprowadza się do rozmowy o tym jaka platforma nocode jest najlepsza. To nie jest prosta decyzja dla osoby która nie poświęciła setek godzin na ich testowanie - na swoich stronach każdy produkt stroi swoje piórka i w okrągłych słowach opisuje swoje atuty. Trzeba poskrobać pazurkiem by potrafić ocenić wartość tych przechwałek.

Ale nawet gdy mamy pogłębioną wiedzę o danej platformie - wszystko trzeba przepuścić przez filtr wymagań klienta. To zresztą dosyć standardowe podejście do porównywania ofert - określamy swoje oczekiwania a następnie przeglądamy rynek i uzupełniamy pozycje dla każdego produktu.

Niestety idąc tą drogą zderzymy się z praktyką - którą mocno poznałem pracując przy produktach chmurowych w Chmurze Krajowej - nieporównywalności produktów. Polega ona na tym, że teoretycznie ten sam produkt - na przykład wirtualna maszyna - opisany jest parametrami niedającymi się wygodnie porównywać między konkurentami. Np.  "1 vCPU, 3 GB RAM" oraz "1 vCPU, 4 GB RAM". W platformach nocode, choć myślę, że nie wynika to z biznesowego cynizmu, równie trudno porównywać atrybuty platform.

List of no-goes

Dlatego rozmawiając z klientem o rekomendowanej platformie zaczynam od stworzenia listy wymagań krytycznych dla jego biznesu. Zazwyczaj te pozycje się powtarzają w wielu biznesach, dlatego korzystam z krótkiej checklisty.

Mobile native czy web

Chcemy aplikację webową czy natywną. Warto dodać, że klient może nie wiedzieć czego chce, dlatego dobrym pytaniem wspierającym jest:

• Jakie będzie główne źródło akwizycji użytkowników? Jeśli to App Store - aplikacja natywna, jeśli Google - raczej web app.
• Czy są funkcje zarezerowane dla aplikacji natywnych (np. pobieranie offline)

Ochrona danych osobowych / RODO

Nigdy nie oceniam czy i jak dana platforma spełnia zasady GDPR, uważam, że to złożona materia i należy analizę przeprowadzać ze specjalistami. Niemniej zwracam uwagę na pewne aspekty które mogą pomóc w pierwszej selekcji rozwiązania:

• Lokalizacja datacenter w Europejskim Obszarze Gospodarczym
• Cookie Consent Popup - czyli wyświetlanie popupu z prośbą o zgode na ciasteczka.
• Opcja blokady zakładania ciasteczek bez uprzedniej zgody - sam popup można by i sobie samemu stworzyć, ważne by powstrzymywał platformę przed założeniem ciasteczka przed udzieleniem zgody.
• Zgodność platformy z RODO - przy czym jeśli platforma jest zgodna z RODO nie oznacza to, że aplikacja stworzona na niej będzie zgodna z RODO. Jeśli jednak platforma nie jest zgodna z RODO jest to czerwona flaga.

Właścicielstwo kodu

Aspekt właścicielstwa kodu jest istotny szczególnie w startupach finansowanych zewnętrznie. Często inwestor jest przyzwyczajony do modelu w którym ma świadomość, że buduje jakieś IP (Intellectual Property) które ma rynkową wartość. Niektóre platformy pozwalają na eksport kodu a niektóre - nie. Znam historie w których to zaważyło o porzuceniu ścieżki nocode, ale też słyszałem podejście VC którzy cieszyli się, że ta inicjalna, najbardziej ryzykowna faza startupu jest prowadzona mniej kapitałochłonną technologią.

Przenaszalność

Brzydkie słowo - chodzi o możliwość odejścia z platformy. Większość rozwiązań nocode wiąże użytkownika ze sobą nierozerwalnie. To naturalne w subskrypcyjnych modelach biznesowych. Platformy nocode wertykalnie integrują łańcuch wartości hostingu aplikacji więc to ma też dodatkowy sens.

Bariera wejścia

Staram się ustalić wielkość przedsięwzięcia oraz oszacować zaangażowanie klienta. Czy ma to być projekt solo czy niewielki startup. Jeśli Klient chce sam rozpocząć budowę - zwracam uwagę na złożoność platformy, ile czasu trzeba poświęcić by zbudować pierwszą aplikacje do szuflady a ile czasu zajmuje stworzenie aplikacji produkcyjnej.

Społeczność deweloperów

Łączy się z powyższym - jeśli Klient oczekuje budowania zespołu - jak liczna jest grupa ekspertów na rynku lokalnym i globalnym. Dodatkowo pochodną zazwyczaj jest dostępność materiałów szkoleniowych, kursów, tutoriali na YouTube czy porad na forum.

Dojrzałość platformy

W kontekście - z jakim prawdopodobieństwiem to rozwiązanie może zniknąć z rynku. Zwracam uwagę na wiek platformy oraz zakładkę "showcase" która pokazuje co stworzyli Użytkownicy - ten ostatni sposób już parę razy zdemaskował ciekawie zapowiadające się narzędzie!

Czego nie robię?

Nie zwracam uwagi raczej na cenę, nie staram się porównywać planów ani tych dziwnych parametrów jak jakieś akcje, elementy w bazie etc. To nie do orgarnięcia. Pod koniec dnia jeśli kogoś nie stać na najdroższy cennikowy plan to uważam, nie powinie się pchać w biznes.

Co robię?

Przechodzę przez powyższą listę i szukam krytycznych pozycji z punktu widzenia oczekiwań klienta. Jeśli dostępność kodu jest dla Klienta krytyczna bo finansuje się z publicznego programu który tego oczekuje - Bubble wypada. Jeśli aplikacja jest typowym webowym SaaSem, wypadają mobilne Adalo, Flutterflow czy Bravo Studio. Jeśli Założyciel sam chce działać odpada Flutterflow i Xano a Bubble jest przedstawiony jako platforma która, mimo wszystko, wymaga sporego nakładu czasu.

Czego zabrakło na tej liście? Jaki aspekt wyboru platform nocode jest dla Was istotny?