O czym jest ten film
- Claude Opus 5.5 potrafi budować animowane, responsywne aplikacje i strony — według autora efekty klasy flagowej są w nim o 40% tańsze, więc opłaca się budować więcej ekranów w większej liczbie stylów.
- Rdzeniem filmu jest metoda trzech etapów: zebranie referencji projektowych → zaplanowanie struktury aplikacji → dopracowanie i wdrożenie produktu.
- Etap 1: zamiast opisywać „ładny design” własnymi słowami, podaje się modelowi przykłady sprawdzonych interfejsów — z serwisów Behance, Dribbble, ScreenDesign i Pageflows.
- Etap 2: rozpisanie podróży użytkownika — ekran ładowania, rejestracja, mapa poziomów, quizy z animowaną postacią, ekran celebracji, serie dni, profil — wraz z bazą danych w tle.
- Praktyczna sztuczka: mapa ekranów sklejona w Canvie lub Figmie; autor wspomina, że zna firmy warte miliardy dolarów, które całą pracę projektową robią w samym Figmie.
- Demonstracja: „AI Lingo”, czyli odpowiednik Duolingo do nauki AI z unikalną sową-maskotką, powstał jednym promptem, za pierwszym podejściem.
- Grafiki generuje się w tym samym czacie co kod, a model można w trakcie rozmowy wymienić na inny (np. Astrę).
- Etap 3: krótkie iteracje (poprawka ucinanej animacji skrzydeł, lepsze dźwięki, trudniejsze pytania), potem wdrożenie jednym kliknięciem — aplikacja jest online w około dwie minuty, pod domeną Abacusa lub własną.
- Przed oddaniem produktu klientom Abacus może sam go przetestować w wirtualnym komputerze — klika w aplikację jak człowiek i raportuje błędy (trasy API, autoryzacja, odporność interfejsu, przepływy w przeglądarce).
- Całość dzieje się na platformie Abacus AI, sponsorze odcinka: wiele modeli w jednej subskrypcji, konta użytkowników, płatności przez Stripe i ścieżka publikacji na Androida i iOS.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zamiast opisywać design — pokaż wzorce
Na czym polega: Model nie wie, co masz na myśli, pisząc „zrób ładnie”. Dopiero konkretne ekrany sprawdzonych aplikacji — z Dribbble, Behance, ScreenDesign czy Pageflows — wyznaczają kierunek: typografia, siatka odstępów, kolory, animacje.
Jak stosować: Przefiltruj banki ekranów pod kątem kategorii (np. iOS, ekran logowania, trendy), wybierz kilka projektów i wklej obrazy lub linki do czatu wraz z opisem, co konkretnie chcesz z nich wziąć. Z kilku źródeł złóż „kolaż” — kilka wariantów stylu, a nie jeden wzorzec.
Na co uważać: Referencje służą do ustalenia języka wizualnego, nie do kopiowania cudzego produktu jeden w jeden — zwłaszcza gdy zamierzasz publikować i zarabiać.
2.Najpierw podróż użytkownika, dopiero potem generowanie
Na czym polega: Ładny wygląd to za mało — model musi dostać listę ekranów w kolejności, w jakiej użytkownik je zobaczy: od ekranu ładowania i rejestracji, przez mapę poziomów, po celebrację, serię dni i profil.
Jak stosować: Wypisz ekrany jednym ciągiem w czacie, dodaj wymagania techniczne (np. backend z bazą danych do kont) i dopiero wtedy proś o budowę.
Na co uważać: Nie upychaj w jednym prompcie całej wizji produktu. Plan jest potrzebny, ale nadmiar wymagań narzuconych od razu utrudnia pracę — lepiej podawać instrukcje etapami i korygować po drodze.
3.Zleć modelowi poprawienie własnego promptu
Na czym polega: Surowa lista wymagań działa gorzej niż dopracowany prompt. Model może przeprowadzić z tobą wywiad, uzupełnić braki i oddać ulepszoną wersję — choćby w formie tabeli do wklejenia w nową rozmowę z czystym, bogatym kontekstem.
Jak stosować: Po wklejeniu referencji i szkicu wymagań napisz po prostu: „popraw ten prompt” — dopiero uzyskaną wersję wysyłaj jako właściwe zlecenie.
Na co uważać: Sprawdzaj, czy ulepszona wersja nie odjechała od twojego celu — bywa, że dopisuje funkcje, o które wcale nie prosiłeś.
4.Rozrysuj ekrany w Canvie lub Figmie
Na czym polega: Wklejenie zrzutów ekranu do prostego edytora graficznego i podpisanie ich („onboarding”, „strona główna”) daje mapę całego produktu — można ją pokazać innym albo podpiąć do promptu jako obraz.
Jak stosować: Nie potrzebujesz warsztatu projektanta — wystarczy ułożyć screeny w kolejności i opisać. Autor przypomina, że firmy warte miliardy robią całą pracę projektową w samym Figmie.
Na co uważać: To narzędzie do szybkiego uzgadniania, nie do budowy pełnej dokumentacji — nie poświęcaj mu więcej czasu niż samemu produktowi.
5.Prototyp z jednego promptu to dopiero początek
Na czym polega: Pierwsze podejście daje działającą aplikację, ale nie produkt końcowy. Potem przychodzą poprawki: ucinana animacja skrzydeł maskotki, lepsze efekty dźwiękowe, rosnąca trudność pytań, dłuższe lekcje.
Jak stosować: Po pierwszym uruchomieniu przejdź aplikację jak zwykły użytkownik, zanotuj drobiazgi i wracaj do czatu z małymi, konkretnymi poleceniami.
Na co uważać: Pokazy typu „wszystko jednym promptem” traktuj jako demo możliwości modelu, a nie obietnicę produkcji bez nadzoru.
6.Grafika niech powstaje w tym samym czacie
Na czym polega: Dawniej obrazy wymagały osobnych narzędzi; teraz maskotka, ikony i ilustracje mogą powstawać obok kodu, w jednej rozmowie, a model może sam zdecydować, co wygenerować.
Jak stosować: W prompcie napisz wprost: „jeśli potrzebujesz obrazów, wygeneruj je sam” — i pozwól modelowi skorzystać z jego możliwości graficznych.
Na co uważać: Sprawdzaj spójność stylu między elementami oraz wagę wygenerowanych plików i płynność animacji na słabszych urządzeniach.
7.Testuj automatycznie, zanim pokażesz produkt klientom
Na czym polega: Zanim aplikacja trafi do odbiorców, można zlecić modelowi rolę „inżyniera jakości”: sam otwiera ją w wirtualnym komputerze, klika w przyciski jak człowiek i sprawdza trasy API, zabezpieczenia autoryzacji, odporność interfejsu i przepływy w przeglądarce.
Jak stosować: Po wdrożeniu wersji roboczej napisz: „przejdź przez aplikację jako inżynier jakości, znajdź miejsca, w których się wysypuje, i te, gdzie doświadczenie użytkownika jest słabe”.
Na co uważać: Automat wyłapie błędy techniczne, ale nie zastąpi testów z żywymi ludźmi — subiektywnego odczucia użyteczności nie przetestuje.
8.Wdrożenie bywa kwestią dwóch minut
Na czym polega: Publikacja na subdomenie platformy (lub własnej domenie) odbywa się jednym kliknięciem i zajmuje około dwóch minut; dopiero potem pozostaje droga do sklepów aplikacyjnych.
Jak stosować: Wykorzystaj szybkie wdrożenie do pokazów i zbierania opinii, zanim zainwestujesz w markę, własną domenę i konta deweloperskie.
Na co uważać: Hosting pod cudzą subdomeną to etap przejściowy — produkt komercyjny wymaga własnej domeny oraz zgodności z regulaminami App Store i Google Play.
9.Konta, baza danych i płatności planuj od razu
Na czym polega: Backend — konta użytkowników, zapamiętywanie ich danych, ewentualne rozliczenia — można zamówić tym samym promptem co interfejs; integracja ze Stripe pozwala szybko dodać płatności.
Jak stosować: Już na etapie planowania struktury dopisz do promptu wymaganie bazy danych i logowania, żeby nie przebudowywać aplikacji później.
Na co uważać: Płatności i dane osobowe to obszary, w których trzeba dokładnie sprawdzić, co model faktycznie zbudował — prywatność i bezpieczeństwo transakcji wymagają nadzoru człowieka.
10.Jeden interfejs, wiele modeli — ale zweryfikuj sponsorowany entuzjazm
Na czym polega: Platformy agregujące modele (tu: Abacus AI) pozwalają korzystać z wielu modeli w jednej subskrypcji i przełączać je w trakcie rozmowy — inny do designu, inny do analizy.
Jak stosować: Gdy efekt nie zadowala, zamiast przepisywać prompt od zera, przetestuj ten sam opis w innym modelu — szybko się okaże, czy problem leży w prompcie, czy w modelu.
Na co uważać: Film jest materiałem sponsorowanym, więc zachwyt nad platformą warto zweryfikować własnym testem w darmowym okresie.
Redakcyjne tłumaczenie
Wstęp: trzy etapy od pomysłu do publikacji
Z nowym modelem Claude Opus 5.5 da się budować piękne, responsywne aplikacje i strony — ale tylko wtedy, gdy pracujesz we właściwy sposób. W tym filmie pokażę krok po kroku, jak zrobić to z dowolnym pomysłem, korzystając z bardzo prostego systemu trzech etapów — nawet bez żadnego doświadczenia. Zaparz sobie kawę i zaczynajmy.
Cały proces podzieliłem na trzy proste etapy. Warto wiedzieć, że efekty klasy flagowej są w Opusie 5.5 dostępne o 40% taniej — właśnie dlatego można budować więcej ekranów w większej liczbie stylów. A opisane tu systemy projektowe realnie podnoszą jakość wizualną aplikacji. Jeśli masz pomysł, zbudujesz go nadzwyczaj łatwo, a pod koniec filmu zobaczysz, jak przejść od pomysłu do opublikowanego produktu.
Całość zrealizujemy w jednym narzędziu, bo tak jest najprościej. Będzie nim Abacus AI, sponsor dzisiejszego odcinka: daje dostęp do Opusa 5.5, Astry i innych modeli, ogarnia całą nudną administrację i spina wszystko w jeden system.
(Informacja dodatkowa: tytułowy „vibe coding” to styl pracy, w którym aplikację buduje się głównie rozmową z modelem AI, samodzielnie pisząc niewiele kodu albo wcale.)
Etap 1: zacznij od prawdziwego designu
Zaczynamy od samego początku, czyli od designu opartego na realnych wzorcach. Otwieram Abacusa — link zostawiam w opisie, więc możesz powtórzyć każdy krok. W środku wybierasz dowolny model, na przykład Astrę albo Opusa 5.5, i ruszamy. Na ekranie widać aplikację, którą zrobiłem wcześniej jednym promptem, opierając się wyłącznie na Duolingo — za chwilę zobaczysz, jak do tego doszedłem.
(Informacja dodatkowa: Duolingo to jedna z najpopularniejszych aplikacji do nauki języków, rozpoznawalna dzięki zielonej sowie-maskotce.)
Zanim wybierzemy model, jedna rzecz: Opus 5.5 ma autentycznie nowe i znakomite możliwości. Potrafi tworzyć animowany design — rzeczy, które wyglądają świetnie — nawet bez generowania obrazów, choć z nich również będziemy korzystać.
Pierwszy z trzech etapów to zebranie właściwych referencji projektowych. Wyobraź sobie, że masz przed sobą najlepszego projektanta świata — twoim zadaniem jest wytłumaczyć mu, jak produkt ma wyglądać. Mowa o skali typograficznej, siatce odstępów, zaokrągleniach narożników, tokenach kolorystycznych, animacjach. Tyle że nie zawsze umiemy słowami opisać, czym jest dobry design. Dlatego zamiast opisywać — pokazujemy przykłady ze sprawdzonych aplikacji i systemów.
Skąd je brać? ScreenDesign, Behance, Dribbble, Pageflows — znakomite źródła, pełną listę zostawiam w opisie. Na Behance możesz wejść w kategorie aplikacji webowych i mobilnych. To produkty, które dziś robią dziesiątki tysięcy dolarów — czasem mniej, czasem znacznie więcej — więc zamiast zgadywać, po prostu patrzysz, co je łączy i jaki styl interfejsu chcesz osiągnąć. Podobnie screendesign.com: zwróć uwagę na poziom animacji i wykończenia i pomyśl, ile promptów zajęłoby osiągnięcie czegoś takiego. Jest też pageflows.com i wiele innych serwisów.
Załóżmy, że jesteśmy na Dribbble. Wybieram kategorię iOS i rozglądam się; mogę filtrować po trendach albo wyszukać konkretny typ ekranu, na przykład rejestrację i logowanie. Czyli da się szukać precyzyjnie, ale tak naprawdę chodzi mi po prostu o dobre przykłady. Nawet kalendarz cyklu się znajdzie — może nie najbardziej przydatna aplikacja dla panów wśród widzów, ale już widać, o co chodzi. Przechodzę do sekcji najpopularniejszych i patrzę, co tam jest.
Ja bardzo lubię interfejs Duolingo, ale spójrzcie też na Revolut — powiedzmy, że robicie aplikację finansową. Jeśli powiesz Abacusowi po prostu „zbuduj mi aplikację”, dostaniesz dobrą aplikację. Ale możliwość podpięcia konkretnych ekranów — skopiowanych z tych serwisów — nadaje rozmowie punkt odniesienia i stabilizuje kierunek, czego same opisy nie zapewnią. Chodzi o to, żeby przyjrzeć się, jak te produkty działają, a potem stworzyć kolaż: kilka wariantów, wiele różnych wersji.
Żeby pokazać czysto siłę tego podejścia, pokażę, jak model radzi sobie, patrząc wyłącznie na Duolingo. Powiedzmy, że chcesz zrobić wersję Duolingo do nauki AI — ludzie od razu wiedzą, o co chodzi. Przeglądam więc kolejne ekrany, ten mi się podoba, klikam „kopiuj” i przechodzę z powrotem do Abacusa, gdzie wklejam link do agenta. Potem mogę wrócić i dorzucić kolejne elementy — zależy nam przecież na tym, żeby dało się z nim rozmawiać.
Oczywiście w praktyce nikt nie będzie tylko kopiował i wklejał — robię to wyłącznie po to, żeby pokazać, jak dobre stały się te modele i systemy. Jeśli w którymś momencie zamiast Opusa 5.5 chcesz użyć innego modelu do innego zadania, wystarczy go przełączyć i dodać warianty. A kiedy potrzebujemy obrazów, generujemy je w tym samym czacie — wszystko jest zintegrowane.
Meta-prompting: niech model doprecyzuje twoje zamówienie
Gdy skończysz wskazywać referencje, warto zrozumieć jedną rzecz. Mamy wzorce, ale jeszcze nie opis samego pomysłu — czyli co aplikacja ma robić i jak wyglądać. Możesz poprosić o zwrot w formie tabeli, którą wklejasz do kolejnego promptu, i nic się nie gubi, ani najmniejszy szczegół. Robimy więc tzw. meta-prompting: kopiujemy szkic promptu, pozwalamy Abacusowi przeprowadzić z nami wywiad, a potem otwieramy zupełnie nową rozmowę z doskonałym kontekstem. Właśnie tym się tu zajmiemy.
W praktyce taki prompt może wyglądać tak: „Hej, zbuduj mi wersję Duolingo do nauki AI — Duolingo for AI. Chcę piękną sowę, a aplikacja ma uczyć różnych pojęć ze sztucznej inteligencji. Oprzyj się na załączonych referencjach projektowych i pomóż mi ukształtować i rozbudować aplikację. Ma to być aplikacja mobilna, którą później mogę obrócić w cokolwiek zechcę. Zadbaj o piękny design. Jeśli potrzebujesz generować obrazy, zrób to sam. Wykorzystaj też niesamowite możliwości graficzne Opusa 5.5”.
Naprawdę prosty prompt. Piszę go przy pomocy Gladosa — link w opisie; z nim dostaniesz miesiąc za darmo. Możemy zaczynać i wciskać enter. Ale zanim to zrobimy, musimy ukończyć etap drugi.
Etap 2: struktura i podróż użytkownika
Etap drugi to zrozumienie struktury, czyli drogi, jaką użytkownik przejdzie przez aplikację. Trafienie w design to jedno, ale trzeba też realnie przemyśleć, przez jakie etapy aplikacja ma nas przeprowadzać — dotyczy to zarówno nas, jak i Abacusa, czy jakiegokolwiek modela, z którym akurat pracujecie. Weźmy dla przykładu Duolingo. Na początek potrzebna nam strona rejestracji. Wpisuję więc wprost w czacie:
Chcę ekran ładowania z animacją oraz możliwość zalogowania się i założenia konta. Potem widok mapy, po której przechodzę z poziomu na poziom. Po wejściu do poziomu — animowana postać i pytania do odpowiedzenia. Po ukończeniu poziomu — celebracja, a do tego coś, co pokazuje zdobytą serię dni. Dodatkowo możliwość zmiany zdjęcia profilowego i wszystko, czego można oczekiwać od aplikacji. I równolegle: pełny backend z bazą danych, który spina to wszystko w całość.
Wklejam, dostaję wynik — wygląda dobrze — a teraz poprawmy prompt: „Hej, możesz poprawić ten prompt?”. Dostarczyliśmy już wszystkie informacje potrzebne do ulepszenia. Doklejamy ulepszoną wersję i teraz oficjalnie możemy odpalić, bo mamy strukturę i design.
Sztuczka: mapa ekranów w Canvie albo Figmie
Przy okazji mała sztuczka. Bardzo pomaga otworzyć dowolny program — Canvę czy cokolwiek innego — i po prostu rozrzucić w nim zrzuty ekranu. Ktoś mógłby powiedzieć, że to poziom Leonarda da Vinci, ale chodzi o proste rzeczy: bierzesz screeny, myślisz „to będzie pierwszy ekran”, kopiujesz go na planszę — i tak krok po kroku mapujesz sobie, jak całość będzie wyglądać. Czy budujesz aplikację dla dzieci, dla firmy, czy po prostu coś dla zabawy — możesz z tym zrobić, co chcesz. A gotowy obraz później po prostu podpinasz do promptu.
Użyj dowolnego narzędzia. Przy budowaniu naszego oprogramowania lubimy tak pracować, a znam — dosłownie — firmy warte miliardy dolarów, które robią całą pracę w jednym z programów projektowych. Całkiem niesamowite: siedzą w samym Figmie. Piszesz „onboarding” — i masz wszystkie ekrany onboardingu. Potem „strona główna” — i budujesz dalej, ekran po ekranie. Przy kodowaniu planować trzeba, ale nie należy przesadzać z ilością wymagań narzucanych od razu. Spokojnie można podawać poszczególne instrukcje, a poprawki wprowadzać później.
Efekt: „AI Lingo” zbudowane za jednym podejściem
Tymczasem Abacus zbudował nam AI Lingo. Odświeżam widok, bo po lewej stronie Abacus zadaje pytania doprecyzowujące. Stworzył unikalną sowę, która do nas macha — i popatrzcie, jak dobry wyszedł efekt za pierwszym razem (tzw. one shot). Robi to wrażenie. Wszystko mamy na liście, wszystkie sekcje. Możemy wdrożyć jednym kliknięciem albo otworzyć aplikację w osobnej przeglądarce — wystarczy poprosić: „Hej Abacus, otwórz mi to w nowej przeglądarce, żebym mógł zobaczyć, jak aplikacja wygląda”.
Jesteśmy w AI Lingo. Zakładam konto — i widać, jak wiernie model oddał cały charakter wzorca. Wpisuję imię Jack oraz jeden z najbezpieczniejszych i najbardziej realistycznych adresów e-mail w dziejach. Mogę przetestować wszystko. Ustawiam hasło, dostaję na powitanie trochę konfetti — nieźle jak na start. Pojawia się moduł „Podstawy AI”, wchodzę w niego. Zostałem „AI Apprentice” — uczniem AI. Mogę edytować profil. Szczerze mówiąc, jestem pod wrażeniem tego, co daje się uzyskać z Opusem 5.5 — to wręcz niebywałe.
Wracam na ekran główny i klikam „Start”. Dziesięć punktów XP — model zrozumiał wszystkie szczegóły. „System, który uczy się z danych, aby robić predykcje” — to pewnie machine learning, zaznaczam i sprawdzam następne. „Które z poniższych to przykład AI?” Papierowy kalendarz? Nie — filtr spamu, który uczy się sam. Zaznaczam. Pojawiają się animacje. I przypominam: to wszystko powstało jednym promptem, ja nie tknąłem nic z tego ręcznie. „Czym jest trening?” — pewnie „dostosowywanie modelu na przykładach”. Moi drodzy, idzie nam gładko — moduł ukończony bezbłędnie. Do poprawki zostały tylko drobne obramowania, ale widać, co się stało: aplikacja powstała od ręki, a my odbieramy punkty XP. System je dopisał, mamy nawet licznik serii dni. Jakość designu, jakiej udało się osiągnąć, robi na mnie wrażenie. Wszystko jasne — możemy przejść do kolejnego poziomu.
To aplikacja zbudowana w zasadzie jednym promptem. A jeśli którekolwiek z tych pojęć brzmi dla was jak chińszczyzna, w opisie zostawiam link do mojego pełnego kursu Claude Code. Pomaga budować właśnie na takich platformach: piękne strony, aplikacje i całe systemy — od zupełnego zera do poziomu, na którym tworzysz samodzielnie. W pakiecie dostajecie całą bibliotekę animacji i kompletny „Claude Agentic Operating System”, które pomogą wam tworzyć grafikę, aplikacje i systemy — cokolwiek planujecie.
Etap 3: dopracowanie i wydanie produktu
I to naturalnie prowadzi nas do trzeciego etapu: dopracowania i wydania samego produktu. Wracamy do projektu i chcemy go wdrożyć, ale najpierw kilka zmian. Piszę na przykład: „Hej, w animacjach ptaka ucina mu się część skrzydeł — popraw to. Chcę też lepsze efekty dźwiękowe, kiedy wygrywa. Zrób przegląd pytań: niech stopniowo się trudnią, a lekcje niech będą trochę dłuższe”. Wracasz z takimi uwagami i po prostu dogadujesz się z modelem, aż efekt będzie zadowalający.
Gdy już jesteś zadowolony, obejrzyj aplikację na różnych urządzeniach. Nasza jest zoptymalizowana pod telefony, więc tak właśnie będzie wyglądać. Klikasz „Deploy”, nadajesz nazwę domeny — na przykład „duolingo-example” — i aplikacja trafia na hosting Abacusa. Po niecałych dwóch minutach jest na żywo i można ją otworzyć. Gdybyśmy chcieli domenę własną, nie ma najmniejszego problemu — to tylko przykład.
Otwieramy i mamy działającą aplikację. Oczywiście w rzeczywistości nie skopiowalibyście Duolingo — to wyłącznie przykład pokazujący, że da się odtworzyć cokolwiek. Zrobiliśmy własną postać, która lata po ekranach, i popatrzcie, jak dobrze model pojął jej charakter wizualny.
Inżynier jakości AI: niech automat sam kliknie w aplikację
Zanim aplikacja trafi do pierwszego klienta, zleć Abacusowi przegląd w roli inżyniera jakości. Piszę: „Hej, przejdź przez aplikację jako inżynier jakości AI i ją przetestuj. Znajdź miejsca, w których się wysypuje, i te, w których doświadczenie użytkownika może być słabe — chcę mieć pewność, że produkt jest solidny i przetestowany, zanim oddamy go klientom”.
I teraz najlepsze: Abacus ma do dyspozycji komputer. Sam otworzy w nim aplikację i zacznie ją testować — naciskać przyciski i patrzeć, co się stanie, czyli sprawdzać ją jak człowiek. Jeśli klikniesz w ikonę tego komputera, zobaczysz jego środowisko w tle: aplikacja uruchamia się na maszynie i przechodzi testy. W kolejce: przegląd tras API, zabezpieczenia autoryzacji, odporność interfejsu, testy przepływów w przeglądarce, raporty. Po prostu przetestuje za nas wszystko w tle.
Gdy aplikacja jest już gotowa i unikalna, pozostaje opublikować ją na Androida lub w App Store — jest mnóstwo dobrych poradników szczegółowo opisujących ten ostatni krok; pokażę je na ekranie, żebyście wiedzieli, co robić dalej.
Co dostaliśmy w pakiecie
Warto podsumować, co przeszliśmy w Abacusie. Wszystkie modele w jednej subskrypcji. Zbudowaliśmy aplikacje — mobilne, desktopowe i webowe, w różnych rozmiarach. Korzystaliśmy z inżyniera jakości AI. Ogarnęliśmy bazy danych, więc ludzie mogą zakładać konta, a system zapamiętuje, kim są. Gdybyśmy chcieli, moglibyśmy dodać płatności — wszystko jest podpięte do Stripe, więc pobieranie opłat za tę aplikację byłoby dość proste. Stworzyliśmy wreszcie grafiki w samej aplikacji. Link zostawiam w opisie — wejdźcie, twórzcie i bawcie się dobrze.
Na koniec jedno naprawdę ważne pytanie. Budowanie aplikacji to jedno, ale jeśli naprawdę chcecie zamieniać widzów w kupujących, musicie zrozumieć, jak budować systemy projektowe — i nauczymy się tego razem w filmie, do którego link widnieje obok.