WordPress vs własny kod - co wybrać dla strony firmowej?

Porównuj zakres projektu, nie nazwę technologii

Pytanie „WordPress vs custom” pada w większości pierwszych rozmów o stronie. Zwykle w formie: „a w czym to będzie zrobione”. Odpowiedź zależy od rzeczy, o które jeszcze nikt nie zapytał. Kto będzie publikował treści i jak często. Jakie funkcje strona ma mieć poza opisem oferty. Z jakimi systemami ma się łączyć. Kto ją będzie utrzymywał przez następne lata. Dopiero po tych odpowiedziach nazwa technologii nabiera znaczenia.

Pracujemy w obu podejściach. Budujemy strony na WordPressie i piszemy strony we własnym kodzie PHP, a wybór zapada przy każdym projekcie osobno, na etapie „Cel i zakres”. Dlatego ten poradnik kończy się listą pytań, po których sam zobaczysz, która droga pasuje do Twojej firmy, a nie rekomendacją jednej z nich.

Strona z kilkoma podstronami oferty ma inne potrzeby niż katalog produktów połączony z bazą stanów magazynowych. Zanim porównasz oferty wykonawców, zapisz scenariusze, które mają działać po publikacji. Publikacja nowej realizacji ze zdjęciami. Zmiana opisu usługi i cennika. Dodanie wersji językowej. Wysłanie zapytania i to, dokąd ono trafia. Poproś każdego wykonawcę, żeby pokazał, jak dany scenariusz będzie obsługiwany w jego propozycji. Wtedy porównujesz to samo, a nie dwie nazwy.

Ten temat jest fragmentem większej decyzji o stronie firmowej, od wyboru wykonawcy po utrzymanie. Całość opisujemy w przewodniku o stronach internetowych dla firm z Wielkopolski. Tutaj zajmujemy się jednym pytaniem: na czym tę stronę zbudować.

Co dokładnie porównujesz: trzy warianty i ich odmiany

Pod hasłami „WordPress czy custom” i „CMS czy własny kod” kryją się w ofertach co najmniej cztery różne rzeczy. Zanim porównasz, upewnij się, co kto proponuje.

WordPress na gotowym motywie

WordPress to system zarządzania treścią o otwartym kodzie, rozwijany przez społeczność, z dokumentacją na wordpress.org. Najszybsza w przygotowaniu wersja to gotowy motyw z katalogu albo sklepu, dopasowany kolorami i treścią, często z kreatorem stron typu „przeciągnij i upuść”. Dostajesz dużo funkcji od razu, ale też dużo kodu, którego nie używasz, i zależność od autora motywu.

WordPress z własnym motywem

Ta sama baza, ale motyw pisany dla konkretnej firmy, z własnym projektem graficznym i tylko tymi funkcjami, które są potrzebne. Panel redakcyjny zostaje, kod jest szczuplejszy, a wygląd nie przypomina tysiąca innych stron. Wtyczki ograniczone do kilku sprawdzonych. W ofertach ta wersja bywa nazywana „custom”, choć nadal jest WordPressem.

Własny kod

Strona pisana od podstaw w wybranym języku i frameworku, u nas w PHP, z własnym panelem do edycji albo z podłączonym osobnym systemem do treści. Własny kod nie oznacza pisania każdego elementu od zera. Projekt korzysta z utrzymywanych bibliotek do rzeczy standardowych. Pisze się to, co w Twojej firmie jest inne: obieg zapytań, katalog z parametrami, uprawnienia, połączenie z systemem, którego używacie.

Platforma abonamentowa

Kreator strony w modelu subskrypcji, gdzie hosting, edytor i aktualizacje są po stronie usługodawcy. Strona powstaje w jego narzędziu i działa, dopóki płacisz. Nie ma dostępu do kodu, a zakres funkcji wyznacza plan, który wybrałeś.

Gdy w tym tekście piszemy „WordPress”, mamy na myśli obie wersje, z zaznaczeniem różnic tam, gdzie mają znaczenie. „Własny kod” oznacza stronę pisaną na zamówienie poza WordPressem.

WordPress czy custom: pytania, które rozstrzygają

Siedem pytań, na które odpowiadamy z klientem na etapie „Cel i zakres”. Odpowiedzi zwykle wskazują drogę wyraźniej niż jakakolwiek tabela zalet i wad.

1. Kto i jak często będzie publikował treści. Aktualności co tydzień to inna sytuacja niż zmiana numeru telefonu raz w roku.
2. Jakie funkcje strona ma mieć poza opisem oferty. Formularz zapytania to standard. Konfigurator produktu, panel dla dystrybutorów, rezerwacje z kalendarzem to już osobne moduły.
3. Z jakimi systemami ma się łączyć i co ma między nimi przepływać. CRM, program magazynowy, system rezerwacji, newsletter.
4. Kto będzie stronę utrzymywał. Osoba w firmie, obecny informatyk, wykonawca w ramach opieki, nikt.
5. Jak ma wyglądać edycja. Zmiana tekstu w gotowym miejscu, czy przestawianie sekcji i budowanie nowych podstron.
6. Ile wersji językowych i kto je sprawdza.
7. Co się stanie, gdy za trzy lata zmienisz wykonawcę. Kto wtedy przejmie stronę i co dostanie.

Jeśli większość odpowiedzi brzmi „standardowo, często, własnymi siłami”, WordPress z własnym motywem ma mocne argumenty. Jeśli odpowiedzi krążą wokół obiegu danych, uprawnień i połączeń z systemami, własny kod zaczyna się bronić, bo dopasowanie jest w nim naturalne, a nie dobudowane. Jeśli strona ma być prosta, a Ty chcesz ją zmieniać sam bez wykonawcy, platforma abonamentowa jest do rozważenia, z zastrzeżeniami z osobnej sekcji.

Kiedy WordPress jest dobrym wyborem

WordPress wygrywa tam, gdzie treść jest głównym zadaniem strony, a funkcje mieszczą się w tym, co system i sprawdzone wtyczki robią od lat.

Regularna publikacja przez zespół

Gdy firma publikuje poradniki, aktualności, oferty pracy albo realizacje, panel redakcyjny WordPressa jest dojrzałym narzędziem. Role użytkowników, wersje wpisów, podgląd przed publikacją, biblioteka mediów, planowanie publikacji. Osoba z marketingu nauczy się go w jedno popołudnie, a nowy pracownik prawdopodobnie już go zna. Przy odbiorze sprawdź to na własnych materiałach: dodaj realizację ze zdjęciami, zmień opis usługi, podmień zdjęcie na stronie głównej. Sama obecność panelu nie oznacza, że każda część strony będzie edytowalna. Zapytaj wprost, które elementy zmienisz sam, a które wymagają programisty.

Standardowe funkcje

Blog, galeria realizacji, formularze, mapa, wersje językowe, podstawowe SEO, prosty sklep. Dla każdej z tych rzeczy istnieją wtyczki używane na tysiącach stron, co oznacza, że błędy są znajdowane i łatane szybko. Katalog wtyczek na wordpress.org pokazuje datę ostatniej aktualizacji, zgodność z wersją systemu i liczbę aktywnych instalacji. Wtyczka, której autor nie aktualizował od dwóch lat, jest ryzykiem bez względu na to, jak dobrze działa dziś.

Dostępność wykonawców

WordPress zna duża część agencji i freelancerów. Jeśli kiedyś zmienisz wykonawcę, znajdziesz kogoś, kto przejmie stronę, zwłaszcza gdy motyw jest napisany czysto i udokumentowany. To jeden z najmocniejszych argumentów za WordPressem dla firmy, która nie chce być związana z jednym dostawcą.

Na co uważać

Przy funkcjach opartych na wtyczkach zapytaj o licencje: czy są jednorazowe, czy roczne, na czyje konto, i co się stanie, gdy przestaniesz je odnawiać. Zapytaj o zgodność dodatków ze sobą, bo dwie wtyczki, które osobno działają, razem potrafią się psuć. Zapytaj też o odpowiedzialność za aktualizacje, bo lista kilkunastu dodatków nie jest jeszcze opisem działającego procesu. Potrzebna jest próba całej ścieżki użytkownika, na przykład od wyboru produktu do potwierdzenia zapytania, po każdej większej aktualizacji.

Kreatory stron typu „przeciągnij i upuść” ułatwiają samodzielne budowanie podstron, ale dokładają kod i spowalniają stronę. Jeśli zespół ma układać nowe strony sam, kreator ma sens. Jeśli ma zmieniać treść w gotowych sekcjach, lepszy jest własny motyw z ustalonymi polami, bo nie da się w nim przypadkiem rozsypać układu.

Kiedy własny kod ma przewagę

Własny kod wygrywa tam, gdzie strona jest narzędziem z własną logiką. Albo tam, gdzie liczy się pełna kontrola nad tym, co jest w kodzie.

Uprawnienia, obieg danych, integracje

Rozważ własny kod, gdy projekt obejmuje specyficzne uprawnienia, niestandardowy obieg danych lub połączenia z systemami firmy. Przykłady z naszych rozmów. Katalog produktów pobierający stany i ceny z programu magazynowego. Panel dla dystrybutorów z cennikami zależnymi od umowy. Formularz zapytania, który tworzy zlecenie w systemie firmy i przydziela je handlowcowi. W WordPressie da się część z tego zbudować wtyczkami i własnym kodem, ale każdy taki element jest dobudówką do systemu zaprojektowanego do publikowania treści. We własnym kodzie ten obieg jest rdzeniem projektu.

Wydajność i powierzchnia ataku pod kontrolą

We własnym kodzie strona ładuje tylko to, co zaprojektowano. Nie ma skryptów z wtyczek, których nikt nie używa, ani panelu logowania pod znanym wszystkim adresem. Mniej elementów oznacza mniej miejsc, w których coś może się zepsuć albo zostać wykorzystane. Praca nad bezpieczeństwem zostaje, o czym piszemy w osobnej sekcji, ale zmienia charakter.

Strona oferty osobno, narzędzie dla zespołu osobno

Oddziel stronę oferty od narzędzia do codziennej pracy. Firmowa witryna może działać niezależnie od aplikacji dla zespołu, a formularz przekazywać zapytania do CRM-u. Taki podział warto ocenić pod kątem dostępu do danych, utrzymania i przyszłych zmian. Zdarza się, że strona oferty zostaje na WordPressie, a panel dla klientów B2B powstaje we własnym kodzie obok niej. Jak może wyglądać taki panel, opisujemy na stronie paneli klienta B2B, a przepływ zapytań ze strony do systemu w poradniku o integracji strony z CRM-em.

Na co uważać

Własny kod wymaga wykonawcy, który go utrzyma, i dokumentacji, która pozwoli komuś innemu go przejąć. Zapytaj o prawa do kodu, repozytorium, użyte biblioteki i ich licencje, oraz o to, jak wygląda edycja treści. Panel pisany na zamówienie bywa prostszy niż WordPress, bo ma tylko potrzebne pola, ale może też być uboższy, jeśli nikt nie zaplanował, że za rok dojdzie blog. Zapytaj też, co się stanie, gdy wykonawca zniknie z rynku: czy kod i dokumentacja są u Ciebie, czy tylko u niego.

Platforma abonamentowa: co sprawdzić przed podpisaniem

Kreatory w abonamencie kuszą tym, że stronę można zrobić w weekend i zmieniać bez nikogo. Dla jednoosobowej firmy usługowej z prostą ofertą to bywa rozsądny start. Przed wyborem sprawdź jednak kilka rzeczy dla konkretnej konfiguracji. Sama nazwa platformy nie rozstrzyga, czy strona będzie dobrze widoczna w Google i czy da się ją kiedyś przenieść.

• Eksport treści. Czy wyciągniesz teksty, zdjęcia i strukturę w formie, którą da się użyć gdzie indziej, czy tylko zrzut ekranu.
• Własna domena i certyfikat. Czy strona działa pod Twoim adresem, czy pod subdomeną usługodawcy, i kto zarządza domeną.
• Przekierowania. Czy możesz ustawić przekierowanie 301 ze starego adresu na nowy. Bez tego przebudowa albo przenosiny kosztują ruch z Google.
• Metadane i adresy. Czy edytujesz tytuły, opisy, adresy podstron i tekst alternatywny zdjęć, czy platforma generuje je sama.
• Wersje językowe. Czy są w planie, czy wymagają drugiej strony.
• Limity planu. Liczba podstron, produktów, formularzy, transfer, miejsce na pliki, i co się dzieje po ich przekroczeniu.
• Integracje. Czy formularz wyśle dane do Twojego CRM-u albo arkusza, czy tylko na e-mail.
• Analityka i zgody. Czy wepniesz Google Tag Manager i baner zgód zgodny z RODO, czy jesteś ograniczony do narzędzi platformy.
• Co się dzieje, gdy przestaniesz płacić. Czy strona znika od razu, czy jest okres na przeniesienie.

Zapytaj też, kto odpowiada za kopie zapasowe i czy możesz je pobrać. Platforma utrzymuje serwery, ale nie odtworzy treści, którą usunąłeś przez pomyłkę, jeśli plan tego nie obejmuje. Jak przenieść stronę bez utraty adresów, gdy przyjdzie na to czas, opisujemy w poradniku o przeniesieniu strony i przekierowaniach.

Porównanie w jednej tabeli

Tabela zbiera różnice, które w rozmowach wracają najczęściej. Każdy wiersz jest uogólnieniem i konkretny projekt może wyglądać inaczej.

Jeśli po przeczytaniu tabeli nadal nie wiesz, wróć do siedmiu pytań z sekcji o rozstrzygających pytaniach. Tabela mówi, czym warianty się różnią. Pytania mówią, które różnice są dla Ciebie istotne.

Bezpieczeństwo: skąd biorą się włamania i kto za nie odpowiada

Włamania na strony firm rzadko są wymierzone w konkretną firmę. Zwykle to automaty, które przeszukują internet w poszukiwaniu znanych luk w nieaktualnym oprogramowaniu i słabych haseł. Technologia zmienia miejsce, w którym trzeba uważać, ale nie zwalnia z uwagi.

WordPress

Rdzeń WordPressa ma zespół bezpieczeństwa, regularne wydania i automatyczne aktualizacje poprawek, co opisuje strona o bezpieczeństwie WordPressa. Wtyczki i motywy piszą tysiące niezależnych autorów o różnym poziomie staranności, dlatego to je trzeba wybierać i aktualizować najuważniej. Do tego dochodzi panel logowania pod przewidywalnym adresem, który automaty próbują na każdej stronie. Oficjalny poradnik zabezpieczania WordPressa zaleca między innymi aktualizacje, ograniczanie dostępu, silne hasła, kopie zapasowe i uprawnienia plików na serwerze. Od siebie dodajemy: osobne konta dla każdej osoby, bez wspólnego loginu „admin”, uwierzytelnianie dwuskładnikowe, usuwanie wtyczek, których nikt nie używa, i zakaz edycji plików motywu z poziomu panelu.

Własny kod

We własnym kodzie nie ma cudzych wtyczek, więc odpowiedzialność za każdą linię leży po stronie wykonawcy. Najczęstsze klasy błędów w aplikacjach webowych opisuje OWASP Top 10: wstrzykiwanie zapytań do bazy, błędy w uwierzytelnianiu i kontroli dostępu, niebezpieczna konfiguracja, przestarzałe komponenty. Zapytaj wykonawcę, jak sprawdza dane wejściowe z formularzy, jak przechowuje hasła, jak obsługuje przesyłane pliki i jak aktualizuje biblioteki. Konkretne wytyczne dla programistów zbiera OWASP Cheat Sheet Series. Jeśli wykonawca nie zna tych dokumentów, to sygnał ostrzegawczy niezależnie od technologii.

Wspólne dla wszystkich

• HTTPS na całej stronie, z automatycznym odnawianiem certyfikatu. Sam certyfikat nie zamyka tematu bezpieczeństwa.
• Hosting z aktualną wersją PHP i bazy, z izolacją od innych kont na tym samym serwerze.
• Kopie zapasowe w innym miejscu niż strona, z odtworzeniem sprawdzonym co najmniej raz.
• Dostępy imienne, przekazywane uzgodnionym kanałem, odbierane przy odejściu pracownika albo zmianie wykonawcy.
• Formularze z ochroną przed spamem i limitem prób. Stosujemy Cloudflare Turnstile, bo nie każe klientowi rozwiązywać zagadek.
• Dane z formularzy przetwarzane zgodnie z RODO: polityka prywatności, zgody, minimalny zakres pól. Przepisy znajdziesz w rozporządzeniu na EUR-Lex, a wyjaśnienia na stronie UODO.
• Monitoring dostępności i powiadomienie, gdy strona przestaje odpowiadać albo zmienia się jej zawartość bez Twojej wiedzy.

Bezpieczeństwo wymaga pracy również po wdrożeniu, w każdym wariancie. Jednorazowa konfiguracja ani sam certyfikat HTTPS nie zamykają tego tematu.

Utrzymanie po publikacji: co się dzieje co miesiąc

Strona zaczyna się starzeć w dniu publikacji. Różnica między wariantami polega na tym, co i jak często trzeba robić, i kto to robi.

Ustal właściciela domeny, dostęp do hostingu i repozytorium, zasady kopii zapasowych oraz sposób zgłaszania awarii. Zapytaj, co obejmuje opieka, a co będzie osobno wycenianą zmianą. U nas opiekę po publikacji ustalamy osobno: aktualizacje, kopie zapasowe, monitoring i wprowadzanie zmian. Oferta opieki określa obsługiwane elementy, sposób zgłaszania problemów oraz czas reakcji. Budowę i utrzymanie wyceniamy indywidualnie na podstawie zakresu.

Co dostajesz przy przekazaniu

Niezależnie od technologii, przy „Publikacji i przekazaniu” powinieneś dostać listę. Dostępy do panelu, hostingu i domeny, instrukcję obsługi ustalonych funkcji, informację o użytych usługach i licencjach, oraz zasady opieki. Przy własnym kodzie dodatkowo dostęp do repozytorium i dokumentację techniczną. Przy WordPressie listę wtyczek z informacją, które są płatne i na czyje konto. Dobrze przekazany projekt ułatwia zmianę zespołu, niezależnie od wybranej technologii.

Wydajność i SEO: czy technologia o tym decyduje

Nie. Własny kod nie oznacza automatycznie szybszej strony, a WordPress wolniejszej. Wynik zależy od obrazów, skryptów zewnętrznych, sposobu renderowania i hostingu. Strona na WordPressie z lekkim motywem, pięcioma wtyczkami i dobrym hostingiem bywa szybsza niż własny kod z dziesięcioma skryptami śledzącymi i filmem na pierwszym ekranie.

Zamiast wierzyć deklaracjom, poproś o pomiary gotowych podstron na telefonie, z formularzem i analityką, bo one dokładają najwięcej. Miary, które Google bierze pod uwagę, opisuje dokumentacja Core Web Vitals na web.dev, a sprawdzisz je w PageSpeed Insights pod adresem pagespeed.web.dev. Różnica między wariantami polega na tym, gdzie leży dźwignia. W WordPressie optymalizacja oznacza zwykle odchudzanie: mniej wtyczek, pamięć podręczna, lżejszy motyw. We własnym kodzie oznacza projektowanie od początku tak, żeby nie było czego odchudzać, co wymaga wykonawcy, który o tym myśli.

Z SEO jest podobnie. Google nie premiuje technologii, ocenia stronę. Nagłówki, adresy, metadane, mapa witryny, przekierowania, szybkość i treść działają tak samo w obu wariantach. Podstawy opisuje przewodnik Google dla początkujących. W WordPressie większość z tego załatwia wtyczka SEO. We własnym kodzie te elementy muszą być zaprojektowane, co przy porządnym wykonawcy jest standardem, a przy niedbałym luką. Zapytaj, jak wygląda edycja tytułu i opisu podstrony, czy mapa witryny powstaje sama i jak ustawisz przekierowanie, gdy zmienisz adres.

Wersje językowe zasługują na osobne pytanie. W WordPressie obsługują je wtyczki, dojrzałe, ale dokładające złożoności przy każdej aktualizacji. We własnym kodzie wielojęzyczność trzeba zaplanować od początku, bo dodanie jej później oznacza przebudowę. Co jeszcze trzeba ustalić przy stronie w kilku językach, opisujemy w poradniku o stronie wielojęzycznej.

Jak ten wybór wygląda w różnych firmach

Ta sama decyzja wygląda inaczej w zależności od tego, co strona ma robić. Poniżej to, co w każdej branży przesądza najczęściej, bez gotowej odpowiedzi, bo tę ustalamy przy każdym projekcie osobno.

Firma usługowa: instalacje, serwis, naprawy

Strona ma opisać usługi, obszar działania i prowadzić do zgłoszenia. Funkcje są standardowe, a edycja rzadka. Przesądza to, kto będzie dodawał realizacje i czy zgłoszenie ma trafiać do systemu, którego używa serwis. Jeśli zgłoszenia idą na e-mail, każdy wariant to udźwignie. Jeśli mają tworzyć zlecenie w aplikacji serwisowej, liczy się, co ta aplikacja udostępnia, a technologia strony jest wtórna.

Produkcja i usługi B2B

Przesądza katalog i to, skąd pochodzą dane. Katalog z kilkudziesięcioma produktami i ręczną aktualizacją da się zbudować w obu wariantach. Katalog z parametrami pobieranymi z programu produkcyjnego, cennikami dla grup klientów i zapytaniem ofertowym z załącznikami to projekt, w którym obieg danych jest ważniejszy niż publikowanie treści. Przy Nomatec zakres obejmował stronę, branding i CRM, więc pytanie o technologię padło razem z pytaniem, jak zapytania mają trafiać do zespołu. Jak projektujemy taką stronę, opisujemy na stronie stron dla firm produkcyjnych.

Handel i sklep

Przesądza liczba produktów, źródło danych o stanach i to, czy sprzedajesz tylko online. Sklep na WordPressie z WooCommerce jest sprawdzoną drogą dla asortymentu aktualizowanego ręcznie i standardowych płatności. Sklep połączony z magazynem, hurtownią i kilkoma kanałami sprzedaży zaczyna wymagać własnych modułów albo dedykowanej platformy sklepowej. Platformy abonamentowe dla sklepów mają własne zalety i ograniczenia, które sprawdzasz tak samo jak przy stronie. Od czego zacząć, opisujemy w poradniku o tym, jak zacząć sklep internetowy.

Gastronomia

Strona ma pokazać menu, godziny i prowadzić do rezerwacji albo zamówienia. Przesądza to, kto zmienia menu i jak często, oraz czy rezerwacje obsługuje zewnętrzny system. Przy częstych zmianach menu panel WordPressa albo prosty własny panel z jednym polem są równie dobre. Liczy się to, czy ktoś w lokalu umie go użyć z telefonu. Rezerwacje najczęściej są widżetem zewnętrznego systemu, więc technologia strony ma tu niewielkie znaczenie.

Firma budowlana i remontowa

Strona żyje realizacjami. Przesądza to, jak często je dodajecie i w jakiej formie: zdjęcia z opisem i zakresem, czasem przed i po. Panel redakcyjny z biblioteką mediów jest tu wygodny, a funkcje poza galerią i formularzem rzadko wykraczają poza standard. Jeśli chcecie oddzielnych ścieżek dla inwestorów prywatnych i generalnych wykonawców, to kwestia struktury treści, a nie technologii. Więcej o takiej stronie piszemy w poradniku o stronie dla firmy budowlanej.

Deweloper

Strona dewelopera jest bazą ofert z prezentacją. Przesądza źródło danych o domach i mieszkaniach, częstotliwość zmian statusów i to, czy zapytanie ma wskazywać wybraną ofertę i trafiać do CRM-u biura sprzedaży. Interaktywny plan osiedla, taki jak na stronie VPM Development, wymaga danych przypiętych do rysunku i logiki, która je wyświetla. Taki zakres da się zbudować w obu wariantach, ale im więcej danych ma płynąć z innego systemu, tym mocniejsze argumenty za kodem pisanym pod ten obieg. Zakres opisujemy na stronie stron dla deweloperów.

Przykład z biurka: dwie firmy, dwie różne odpowiedzi

Dwa anonimowe przypadki z tego samego kwartału pokazują, jak te same pytania prowadzą w różne strony.

Firma szkoleniowa

Firma prowadząca szkolenia dla kierowców zawodowych przyszła z prośbą o „stronę w nowej technologii, bo WordPress jest stary”. Krok pierwszy: pytania o scenariusze. Okazało się, że dwie osoby publikują terminy szkoleń co tydzień, dodają aktualności i zmieniają cennik przed każdym sezonem. Funkcje poza tym: formularz zapisu na termin i mapa dojazdu. Integracji brak, zapisy trafiają na e-mail i do arkusza.

Krok drugi: sprawdzenie obecnej strony. Kłopoty brały się z motywu ze sklepu, z czterdziestu wtyczek, z których firma używała sześciu, i z kreatora, który rozsypywał układ przy każdej zmianie. Sam system był aktualny. Krok trzeci: dwa warianty zakresu na piśmie. WordPress z własnym motywem i polami do edycji terminów, oraz własny kod z własnym panelem. Przy porównaniu scenariuszy wyszło, że panel redakcyjny z rolami i planowaniem publikacji jest tu główną funkcją, a reszta to standard. Firma wybrała WordPress z własnym motywem i listą pięciu wtyczek. Opieka obejmuje aktualizacje z testem ścieżki zapisu po każdej z nich.

Producent elementów metalowych

Firma produkująca elementy dla przemysłu chciała „zwykłą stronę z katalogiem”. Krok pierwszy: te same pytania. Treści zmieniają się rzadko, ale katalog ma kilkaset pozycji z parametrami, które już są w programie produkcyjnym, i firma nie chce ich wpisywać drugi raz. Dystrybutorzy mają dostać cenniki zależne od umowy, a zapytanie ofertowe ma trafiać do handlowca przypisanego do regionu.

Krok drugi: sprawdzenie, co udostępnia program produkcyjny. Miał eksport danych w ustalonym formacie, co otworzyło drogę do automatycznego katalogu. Krok trzeci: dwa warianty zakresu. WordPress z wtyczkami do katalogu, importu i stref cenowych, oraz własny kod z katalogiem czytającym eksport, panelem dystrybutora i obiegiem zapytań. Przy porównaniu scenariuszy wyszło, że w pierwszym wariancie każda z tych funkcji byłaby osobną wtyczką z osobnym cyklem aktualizacji, a logika cenników i tak wymagałaby własnego kodu. Firma wybrała własny kod, z osobnym, prostym panelem do treści o firmie. Opieka obejmuje monitoring importu i aktualizacje bibliotek.

W obu przypadkach decyzja zapadła po spisaniu scenariuszy i porównaniu dwóch zakresów na piśmie. Nazwa technologii pojawiła się na końcu, a nie na początku.

Pytania do wykonawcy, częste błędy i słownik

Przed podpisaniem umowy zadaj każdemu wykonawcy te same pytania. Odpowiedzi porównasz łatwiej niż oferty pisane w różnych układach.

Pytania do wykonawcy

1. Pokaż, jak w Twojej propozycji dodam realizację ze zdjęciami, zmienię opis usługi i dodam podstronę.
2. Które elementy strony zmienię sam, a które wymagają programisty.
3. Jakie wtyczki albo biblioteki planujesz, kto je utrzymuje i jakie mają licencje.
4. Kto odpowiada za aktualizacje po publikacji i co się dzieje, gdy aktualizacja coś zepsuje.
5. Gdzie będą kopie zapasowe i kiedy ostatnio odtwarzałeś stronę z kopii.
6. Jak zabezpieczasz panel logowania i formularze.
7. Czy dostanę prawa do kodu i projektu, dostęp do repozytorium i dokumentację.
8. Jak wygląda zmiana adresu podstrony i ustawienie przekierowania.
9. Pokaż pomiar szybkości gotowej strony, którą zrobiłeś w tej technologii, na telefonie.
10. Co dostanę przy przekazaniu i co obejmuje opieka, a co jest osobno wycenianą zmianą.

Najczęstsze błędy przy wyborze

• Wybór technologii przed spisaniem scenariuszy. Potem okazuje się, że panel nie obsługuje tego, co firma robi codziennie.
• Utożsamienie „custom” z własnym kodem, gdy oferta dotyczy własnego motywu WordPressa. Obie rzeczy są w porządku, ale to różne zakresy.
• Wybór WordPressa „bo wszyscy go znają”, a potem motyw ze sklepu z kreatorem, którego nikt w firmie nie umie obsłużyć.
• Wybór własnego kodu bez pytania o dokumentację i repozytorium. Po odejściu wykonawcy nikt nie potrafi strony przejąć.
• Pominięcie utrzymania w porównaniu ofert. Tańsze wdrożenie z drogą opieką albo bez opieki kosztuje więcej w drugim roku.
• Zakładanie, że własny kod jest sam z siebie szybki i bezpieczny. Wymaga pomiaru i pracy tak samo jak WordPress.
• Platforma abonamentowa wybrana bez sprawdzenia eksportu i przekierowań. Przy przenosinach firma traci treści albo ruch.
• Decyzja o sklepie albo panelu klienta w połowie projektu. Zmiana zakresu oznacza powrót do etapu „Cel i zakres”, czasem ze zmianą technologii.

Słownik pojęć

• CMS. System zarządzania treścią, czyli panel, w którym zmieniasz teksty i zdjęcia bez programisty. WordPress jest jednym z nich.
• Motyw. Warstwa wyglądu i układu w WordPressie. Gotowy ze sklepu albo pisany dla Twojej firmy.
• Wtyczka. Dodatek do WordPressa dokładający funkcję: formularz, SEO, tłumaczenia, sklep. Każda ma własnego autora i własne aktualizacje.
• Kreator stron. Narzędzie do układania podstron przez przeciąganie sekcji. Wygodne dla zespołu, dokłada kod.
• Własny kod, strona dedykowana. Strona pisana na zamówienie poza gotowym systemem, z własnym panelem albo podłączonym systemem do treści.
• Framework. Zestaw gotowych, utrzymywanych elementów, na których pisze się własny kod, żeby nie wymyślać standardowych rzeczy od nowa.
• Headless CMS. Osobny system do treści, z którego strona pobiera dane przez API. Łączy panel redakcyjny z własnym kodem strony.
• API. Sposób, w jaki jeden system udostępnia dane drugiemu. Od niego zależy, czy integracja jest możliwa.
• Repozytorium. Miejsce przechowywania kodu z historią zmian. Dostęp do niego jest częścią przekazania projektu we własnym kodzie.
• Kopia robocza, staging. Kopia strony pod adresem tymczasowym, na której sprawdza się aktualizacje i zmiany przed publikacją.
• Licencja GPL. Licencja WordPressa i większości wtyczek, która pozwala używać i zmieniać kod. Zasady opisuje strona o licencji WordPressa.
• Uwierzytelnianie dwuskładnikowe. Logowanie hasłem i kodem z aplikacji albo telefonu. Utrudnia logowanie z wykradzionym hasłem.
• Powierzchnia ataku. Wszystkie miejsca, przez które ktoś może próbować dostać się do strony: panel, formularze, wtyczki, serwer. Im mniej, tym łatwiej pilnować.

Jak to wygląda w naszym procesie

Decyzja o technologii zapada na etapie „Cel i zakres”, gdy znamy ofertę, klientów, obecną stronę i listę funkcji oraz materiałów. Na etapie „Treści i projekt” ustalamy, które teksty, zdjęcia i podstrony będziesz aktualizować samodzielnie, i dobieramy sposób edycji. Na etapie „Wdrożenie i sprawdzenie” budujemy stronę, konfigurujemy uzgodnione funkcje i sprawdzamy wersję mobilną, formularze oraz linki. Przy „Publikacji i przekazaniu” uzgadniamy domenę i hosting, przekazujemy dostępy i instrukcję, a zasady opieki określamy osobno. Zakres projektu, wdrożenia i opieki opisujemy w ofercie stron internetowych dla firm.

Zacznij od listy materiałów do strony i opisu funkcji, które zbieramy w poradniku o tym, co przygotować do strony internetowej. Następnie sprawdź, co wpływa na indywidualną wycenę. Jeśli wygodniej Ci opisać to w formularzu, brief strony WWW pyta o rodzaj strony, skalę, obecną stronę i to, kto przygotowuje treści.

TL;DR

• Porównuj zakres i scenariusze pracy, a nie nazwę technologii. Spisz, co strona ma robić po publikacji.
• „Custom” w ofercie może oznaczać własny motyw WordPressa albo własny kod. Zapytaj, o które chodzi.
• WordPress ma przewagę przy regularnej publikacji, standardowych funkcjach i łatwej zmianie wykonawcy.
• Własny kod ma przewagę przy uprawnieniach, obiegu danych, integracjach i kontroli nad tym, co jest w kodzie.
• Platforma abonamentowa wymaga sprawdzenia eksportu, przekierowań, metadanych i limitów przed podpisaniem.
• Bezpieczeństwo i utrzymanie to praca po publikacji w każdym wariancie. Ustal, kto ją wykonuje i co obejmuje.
• Szybkość i SEO zależą od wdrożenia, a nie od technologii. Proś o pomiary gotowych stron.
• Poproś o dwa zakresy na piśmie i porównaj je pytaniami z tego poradnika.

FAQ