Zanim zacząłem pokazywać wygenerowani.pl komukolwiek, zrobiłem coś prostego: zostałem swoim pierwszym klientem.

Mam software house — Appko. Programuję w Ruby on Rails, sprzedaję development, konsulting, budowę MVP. Klasyczna sytuacja: budujesz rzeczy dla innych, ale własna strona… odkładana w nieskończoność.

Tym razem postanowiłem zrobić to inaczej.

Nie „zrobić stronę”.

Tylko wygenerować ją jak użytkownik.

Punkt wyjścia

Zamiast Figmy, zamiast kodu, zamiast długiego procesu — zacząłem od jednego prompta.

Nie był krótki. I to jest ważne.

Bo jakość wyniku w takich systemach bardzo mocno zależy od jakości wejścia — im bardziej precyzyjny opis (biznes, ton, struktura, styl), tym mniej poprawek później .

Mój prompt wyglądał mniej więcej tak:

Język treści strony: polski...
[...]
Tworzymy strony, które trwają.
[...]
3 karty usług, sekcja projektów, blog, o mnie, kontakt...

To nie był „zrób mi stronę”.

To był brief jak dla designera + developera w jednym.

Co się wydarzyło dalej

Efekt po pierwszym wygenerowaniu?

~90% gotowe.

Bez pisania kodu.

Bez projektowania layoutu.

Bez iterowania przez tygodnie.

Dostałem:

strukturę strony
copy dopasowane do usługi
layout
komponenty
sekcje blogowe
spójny styl wizualny

To dokładnie odpowiada temu, jak działają nowoczesne generatory stron — zamieniają opis w layout, treść i kod jednocześnie, korzystając z modeli językowych i wzorców UI .

Co trzeba było zrobić ręcznie

Nie wszystko było idealne.

I dobrze.

AI nie zastępuje myślenia — przyspiesza wykonanie.

Finalnie zrobiłem tylko:

podpięcie domeny
wymianę obrazków
lekkie poprawki treści
dodanie realnych wpisów blogowych

I to tyle.

Najważniejszy wniosek

To nie jest narzędzie do „robienia stron”.

To jest narzędzie do:

zamiany myślenia w działający produkt

Różnica jest subtelna, ale fundamentalna.

Bo wcześniej proces wyglądał tak:

pomysł → projekt → development → poprawki → publikacja

Teraz wygląda tak:

pomysł → prompt → gotowa strona → drobne poprawki → publikacja

Dlaczego to działa

Większość ludzi robi jeden błąd: traktuje prompt jak wyszukiwarkę.

A to nie działa.

Dobry prompt:

definiuje biznes
określa odbiorcę
ustawia ton
opisuje strukturę strony

Czyli robi dokładnie to, co normalnie robi dobry brief projektowy.

I dlatego działa.

Czy to zastępuje developera?

Nie.

Są rzeczy, których takie podejście jeszcze nie robi dobrze:

bardzo niestandardowe UX
złożone interakcje
skomplikowane aplikacje

To nadal wymaga ręcznej pracy i kodu .

Ale…

Dla:

stron firmowych
landingów
MVP
prostych produktów

To jest wystarczające — i często szybsze niż tradycyjny proces.

Dlaczego zacząłem od siebie

Bo to był najprostszy test.

Nie klient.

Nie sprzedaż.

Nie marketing.

Tylko jedno pytanie:

czy sam bym z tego skorzystał?

Odpowiedź: tak.

Co dalej

To jest pierwszy wpis z serii.

W kolejnych pokażę:

jak wyglądał proces tworzenia innych stron
jakie prompt’y działały, a jakie nie
gdzie są realne ograniczenia
jak wygląda wdrożenie u realnych użytkowników

Bez teorii. Tylko praktyka.

Podsumowanie

Zbudowałem stronę dla własnej firmy.

Nie kodując jej od zera.

Nie projektując w Figmie.

Nie zlecając nikomu.

Tylko opisując, czego potrzebuję.

I to wystarczyło.

Appko.pl - jak zostałem swoim pierwszym klientem