Jaki problem to rozwiązuje
Strony HubSpot budowane na skróty starzeją się źle: szablony klonowane per strona zamiast prawdziwego motywu, zahardkodowana treść, do której marketer nie dosięga, brak dyscypliny stagingu i szybkość strony, która niweczy budżet marketingowy wydany na kierowanie do niej ruchu. Potem każda kampania potrzebuje developera, co jest dokładnie tym, co CMS miał zakończyć.
Jak pracujemy
Budujemy porządny motyw, a nie stertę stron: bibliotekę modułów, gdzie każde edytowalne pole jest świadome, ustawienia motywu dla tokenów marki oraz szablony składane z modułów, żeby nowe strony były konfiguracją, a nie kodem. Ustrukturyzowana treść trafia do HubDB, gdzie jej miejsce - katalog usług, którego częścią jest ta strona, jest napędzany HubDB na naszej własnej stronie, zbudowany tym samym podejściem, które sprzedajemy.
Gdzie budowa potrzebuje logiki, używamy realnych możliwości platformy: HubL do szablonów, funkcji serverless tam, gdzie wymagane jest dynamiczne zachowanie, oraz czystej integracji z formularzami, CTA i śledzeniem, żeby narzędzia marketingu działały od ręki.
Wydajność i utrzymywalność traktujemy jako wymagania, nie aspiracje: kod źródłowy pod kontrolą wersji z CMS CLI, dyscyplina obrazów i skryptów oraz dokumentacja dla tego, kto dotknie motywu po nas.
Deliverables
- Motyw HubSpot z ustawieniami zmapowanymi na tokeny marki
- Biblioteka własnych modułów ze świadomymi edytowalnymi polami
- Dynamiczne strony napędzane HubDB tam, gdzie treść jest ustrukturyzowana
- Funkcje serverless dla dynamicznego zachowania tam, gdzie potrzebne
- Przejście wydajnościowe: Core Web Vitals, dyscyplina obrazów i skryptów
- Kod źródłowy pod kontrolą wersji i dokumentacja motywu