MVP z no-code w Webflow, Airtable i Make

Budowa MVP

Airtable, Webflow i Make to narzędzia z których korzystam najczęściej w kontekście automatyzacji codziennych zadań, procesów biznesowych. Poza tym każde z nich świetnie sprawdza się do budowania MVP produktów lub “obudowania” istniejących produktów funkcjonalnościami, których zaprogramowanie trwałoby wiele tygodni. Do tej pory nie spotkałem szczegółowego i szczerego opisu, pokazującego zarówno dobre jak i złe strony tych narzędzi.

Zakładam, że wszystkie wymienione we wstępie narzędzia są Ci znane albo przynajmniej je kojarzysz. Każde z nich charakteryzuje kategoria “no-code” aczkolwiek w moim wydaniu lepszym określeniem będzie “low-code” i za chwilę wyjaśnię, co mam teraz na myśli. W tej chwili zależy mi na tym aby podkreślić dwa możliwe kierunki wykorzystania tych narzędzi do budowy MVP.

Pierwszy kierunek dotyczy budowy produktu od podstaw i wykorzystania wyłącznie Airtable, Make i Webflow (+ ewentualnie jakieś dodatki np. Whalesync). Natomiast drugi uwzględnia budowanie dodatkowych funkcjonalności do istniejącego produktu, aby np. zweryfikować jej użyteczność, jak najszybciej oddać w ręce użytkowników oraz sprawnie wprowadzać zmiany w oparciu o ich feedback. W obu przypadkach narzędzia no-code sprawdzają się świetnie, jednak nie rzadko wymagają pójścia na kompromisy.

Na podstawie moich doświadczeń mogę jasno stwierdzić, że najważniejsze w wykorzystaniu narzędzi no-code jest dobre orientowanie się w ich możliwościach, uwzględniając w tym ich najnowsze funkcje a także alternatywy, które nieustannie pojawiają się na rynku. Idealnym miejscem do ich odkrywania są zamknięte, płatne społeczności oraz oczywiście https://producthunt.com. Warto też podkreślić, że w praktyce no-code nie zawsze oznacza całkowitego pominięcia programowania. Niezbędnym minimum jest umiejętność pisania nawet podstawowych skryptów JavaScript oraz umiejętność pracy z dokumentacją API. Bez tego szybko dochodzimy do przeszkód, które albo drastycznie zwiększają konieczność kompromisów albo wprost blokują nas przed zrealizowaniem konkretnych, nie rzadko bardzo istotnych funkcjonalności.

Zwykle “sercem” każdej aplikacji opartej o no-code lub low-code jest baza danych stworzona w Airtable. Sam pracuję na kilkudziesięciu bazach, zawierających w sobie setki kolumn i dziesiątki tysięcy rekordów. Na tej podstawie, przygotowałem listę punktów, które warto wziąć pod uwagę przy projektowaniu własnych baz:

• wiedza na temat projektowania klasycznych baz danych jest nieoceniona. Najważniejsze jest zrozumienie koncepcji umożliwiających zachowanie spójności oraz tzw. normalizację (czyli unikanie powtarzania danych na przestrzeni różnych tabel). Wiedzę na ten temat można zdobyć w kursach i książkach o programowaniu
• zachowanie spójności nazw jest niezbędne aby odnaleźć się w większych strukturach. To jakie zasady nazewnictwa wybierzemy nie ma większego znaczenia. Istotne jest tylko to aby się ich trzymać. Uzupełnianie opisów (‘description’) kolumn, bardzo ułatwia późniejsze zrozumienie jaki rodzaj danych przechowujemy w konkretnym miejscu
• do momentu gdy w Airtable pracują osoby, które znają to narzędzie oraz wiedzą na czym polegają automatyzacje, nie ma większego problemu. W sytuacji gdy na danych muszą pracować osoby nietechniczne lub nie biorące udziału w projektowaniu bazy, znacznie lepszym pomysłem jest udostępnienie im Interfejsu Airtable lub widoku Formularza do dodawania danych. W przeciwnym razie łatwo o problemy wynikające z błędnej edycji danych
• Airtable ma dwa największe problemy: skala i cennik. Dość szybko bezpłatna baza wymaga przełączenia się na płatny plan. Sprawa komplikuje się gdy nasz zespół jest duży (np. dostęp dla jednej osoby to $20 w planie rocznym) i szybko robią się z tego duże kwoty. Idealnie jeżeli uda się zachować stan w którym płatne konta mają wyłącznie osoby biorące czynny udział w rozbudowie struktury baz
• z technicznego punktu widzenia, dość problematycznie wypada także wykorzystanie Airtable SDK (korzystałem z wersji dla node.js i php). Szybko widoczne są limity API oraz pojedyncze funkcjonalności (np. paginacja danych, które filtrowane są po stronie naszego własnego interfejsu)
• genialnie sprawdza się fakt, że Airtable daje wizualny wgląd w dane. Nowa funkcja interfejsów tylko w bardzo pojedynczych przypadkach nie była w stanie zrealizować tego, czego potrzebowałem i oceniam ją na 9/10 o ile nie bierzemy pod uwagę wizualnego dostosowania (np. kolorów, etykiet czy własnych stylów). Poniżej przykład interfejsu ułatwiającego pracę z danymi:

Patrząc na to ogólnie, Airtable sprawdza się świetnie na początkowym etapie projektu lub do zrealizowania zadań nie wymagających bardzo dużych zestawów danych. Jeżeli nie zadbamy o poprawną strukturę tabel, szybko robi nam się bałagan (jak w każdej bazie danych czy nawet excelu), który komplikuje praca zespołowa.

Idąc dalej mamy Webflow, które aktualnie jest najlepszym dostępnym na rynku web-builderem. Tutaj podobnie jak w Airtable, mam za sobą wiele projektów, aczkolwiek większość z nich wykorzystywała wyłącznie wbudowane w Webflow opcje, bez zbytniego “naginania” możliwości tego narzędzia. Były jednak wyjątki. W mojej ogólnej ocenie, Webflow perfekcyjnie sprawdzi się na potrzeby budowania stron sprzedażowych czy stosunkowo prostych stron Internetowych. Osobiście nie miałem okazji przekonać się jak wygląda moduł E-commerce, ponieważ niemal zawsze sprzedaję produkty z wykorzystaniem własnych rozwiązań. Moje najważniejsze lekcje i wskazówki wyglądają następująco:

• absurdalne jest dla mnie to, jak trudno pracuje się w Webflow w zespole. Brak możliwości równoległej pracy nad tym samym projektem jest nieakceptowalny. Poza tym wprowadzając zmiany trzeba było zawsze upewnić się, że skończyliśmy nad nimi pracę. W przeciwnym razie “blokowaliśmy” możliwość publikowania zmian do czasu ich ukończenia
• Interfejs Webflow jest świetnie zaprojektowany. Tempo w jakim można wprowadzać zmianym, nawet na wielu podstronach jest wręcz nieosiągalne nawet dla osób sprawnie poruszających się w Tailwind CSS.
• pomimo tego, że Webflow posiada możliwość publikowania stron w innych domenach, powodowało to błędy aktualizowania danych w CMS. Oznacza to, że jeżeli testowaliśmy coś w domenie developerskiej, zespół pracujący z danymi nie mógł wprowadzać żadnych zmian do czasu opublikowania naszych modyfikacji na głównej domenie
• Webflow w wielu przypadkach znacząco utrudnia budowanie interfejsów nakładając dziwne ograniczenia, które trzeba omijać z pomocą JavaScriptu. Najbardziej absurdalnym przykładem jest możliwość dynamicznego wczytywania pól dla pola typu “Select”. W przypadku gdy chciałem w nim umieścić ~250 wpisów, normalnie musiałbym robić to ręcznie.
• Ograniczenia Webflow CMS również wydają się być bardzo nieuzasadnione i niekiedy mocno ograniczające. Samo ograniczenie liczb właściwości w danej kolekcji może doprowadzić do sytuacji w której staniemy przed bardzo trudnym do rozwiązania problemem. Na szczęście zdarza się to rzadko i trzeba po prostu mieć to na uwadze projektując struktury.

• Integracja Airtable i Webflow z pomocą narzędzia whalesync sprawdza się genialnie. Sięgam po nie praktycznie w każdym projekcie.
• Podobnie jak Airtable, Webflow posiada bardzo nieprzyjazne plany cenowe. Konieczność wybrania większego planu tylko ze względu na potrzebę skorzystania z pola typu “file” jest według mnie mało przyjazne dla klienta

Mógłbym wymieniać jeszcze przynajmniej kilkanaście podobnych punktów, jednak wydźwięk pozostanie taki sam: Webflow znacząco przyspiesza pracę nad tworzeniem interfejsów, kosztem problemów związanych z pracą zespołową. Ciekawym rozwiązaniem jest korzystanie z Webflow tylko w zakresie projektów marketingowych (landing page, sprzedaż, blog, newsletter). Wszystkie bardziej zaawansowane rozwiązania sprawdzają się raczej przeciętnie, aczkolwiek i tak udało mi się momentami mocno nagiąć Webflow do swoich potrzeb, z zaangażowaniem mniejszym niż byłoby to potrzebne w przypadku programowania od podstaw. Dodam jeszcze, że świetną techniką pracy z Webflow jest wykorzystanie subdomen. Przykładowo easy.tools przekierowane jest na Webflow a app.easy.tools na naszą aplikację stworzoną w Node.js.

Ostatnim z trójki jest Make.com, który jest wprost niezbędny do tworzenia MVP z Airtable i Webflow. Mówiąc technicznie, Make pełni tutaj rodzaj “back-endu” naszej aplikacji. Airtable do baza danych a Webflow to front-end. Całość współgra ze sobą fenomenalnie i poza problemami indywidualnymi dla narzędzi, trudno wskazać jakiekolwiek wyzwania związane z ich komunikacją. Ponownie jednak podzielę się swoimi spostrzeżeniami, tym razem jednak skupiając się na Make.

• Szybkość i łatwość tworzenia scenariuszy i wprowadzania w nich zmian jest nieziemska. Nawet osoby nietechniczne dość szybko potrafią się w nich odnaleźć. Czas wdrożenia jest zdecydowanie krótszy w przypadku osób potrafiących programować
• W przypadku pracy zespołowej pojawia się problem znany z Webflow. Równoległe wprowadzanie zmian w tych samych scenariuszach nie jest możliwe i co gorsza, może prowadzić do wzajemnego nadpisywania pracy i w żaden sposób nie jest komunikowane przez Make
• Historia wykonań każdego ze scenariuszy jest niezastąpiona, zarówno w kontekście naprawiania błędów jak i analizowania przepływu informacji
• Moduł HTTP jest najważniejszym ze wszystkich, ponieważ umożliwia połączenie się z praktycznie dowolną usługą posiadającą API
• Wdrożenie systemu logowania w Airtable i Make jest dość problematyczne i mało stabilne, aczkolwiek niedawno w dokumentacji trafiłem na sposób wygenerowania tokenów JWT (termin techniczny), ułatwiającym przygotowanie zabezpieczeń scenariuszy
• Podobnie jak w przypadku Airtable, absolutnie krytyczne jest odpowiednie nazewnictwo webhooków, modułów oraz scenariuszy. Bez tego trudno odnaleźć się nawet w małej liczbie automatyzacji
• Nawet w przypadku MVP szybkim problemem może okazać się koszt związany z dużą liczbą operacji. Warto unikać złożonych scenariuszy oraz uruchamiania często nawet tych najprostszych
• Make może pełnić rolę API dla aplikacji opartej o kod. Sprawdza się w tym świetnie, ponieważ poza przyjmowaniem danych, można je także zwracać z pomocą akcji Webhook Response i ustawiać odpowiedź tak, jak tego chcemy
• Czasem pojawia się potrzeba wprowadzenia zmian na przestrzeni różnych scenariuszy. W sytuacji gdy aplikacja działa już na produkcji, prowadzi to do problemów i Make nie adresuje tego poprawnie
• Na przestrzeni ostatnich miesięcy miała miejsce duża, kilkudniowa awaria Make. Wygenerowało to mi mnóstwo dodatkowej pracy i chociaż wszystkie dane udało się bez większych problemów odzyskać, tak brak jakiejkolwiek kontroli nad czasem przywrócenia aplikacji do działania był dużym wyzwaniem.

Podsumowując, Make.com to absolutny lider w swojej kategorii. Pomimo tego, że w ostatnich latach pojawiło się wiele klonów, żadne z nich nie jest na tyle elastyczne jak Make. Pomimo swoich wad, nawet w najbardziej krytycznych momentach spisuje się bardzo dobrze i na potrzeby MVP lub mniej krytycznych funkcji aplikacji, jest więcej niż wystarczający.

Gdybym miał teraz ująć wszystko, co do tej pory napisałem w jednym zdaniu, powiedziałbym, że “Trio Webflow&Make&Airtable sprawdza się genialnie w sytuacji gdy chcemy poruszać się bardzo szybko lub chcemy ‘obudować’ swoją aplikację funkcjami, które można szybko modyfikować i dostosowywać do naszych potrzeb”. Do tego dodałbym jeszcze konieczność zwracania uwagi na problemy w pracy zespołowej (nie są krytyczne ale istotne) i stosunkowo szybką konieczność przejścia na wysokie, płatne plany. Ostatecznie to ostatnie można zaadresować dzięki zniżkom dostępnym na stronie Join Secret. Nie mam z nią żadnego partnerstwa ale sam skorzystałem ze zniżek dla Notion czy Airtable oszczędzając w ten sposób setki dolarów.

Z pewnością w tej wiadomości nie udało mi się w pełni wyczerpać tematu tworzenia MVP z pomocą narzędzi no-code. W kolejnych wydaniach newslettera będę poruszał kolejne istotne wątki z wykorzystywania no-code i automatyzacji do budowy i rozwoju produktów oraz optymalizacji procesów biznesowych.