Jak pracujemy

Współpraca z agencją zwykle wygląda jak czarna skrzynka: pitch deck, umowa, długa cisza, odbiór. Wolimy pracować inaczej, więc poniżej opisujemy typowy przebieg współpracy. W razie potrzeby go dopasowujemy, ale to jest punkt wyjścia.

1. Audyt wejściowy (tydzień 0, stała cena znana z góry)

Wszystko zaczyna się od krótkiej rozmowy wstępnej: bezpłatnej, około 30 minut, na której omawiamy potrzeby i planujemy współpracę. Zwykle pierwszym krokiem po niej jest właśnie ten audyt. Wysyłasz nam adres sklepu, a my przeprowadzamy audyt wydajności z zewnątrz, bez dostępu do Twojego stacka: Lighthouse, Core Web Vitals z danych realnych użytkowników tam, gdzie są dostępne, i trzy poprawki, od których sami byśmy zaczęli. Wyniki omawiamy na rozmowie 30–60 minut i przy okazji prosimy o wgląd w repo, produkcję i realne liczby. Jeśli nie jesteśmy właściwym zespołem do tego zadania, mówimy to wprost jeszcze na tej rozmowie.

Wychodzisz z: zmierzonymi liczbami, listą trzech najważniejszych poprawek i jednostronicowym szkicem zakresu na piśmie: co byśmy zrobili, ile by to kosztowało i jak długo by trwało.

2. Audyt pogłębiony (tygodnie 1–2, stała cena)

Kiedy audyt wejściowy wskazuje na coś większego, to jest następny krok. Czytamy kod, infrastrukturę i analitykę: metryki realnych użytkowników, trace’y po stronie serwera, audyt bundle’a i assetów. Prawdziwa przyczyna wolnej strony rzadko leży tam, gdzie wszyscy jej szukają.

Wychodzisz z:

• pisemnym raportem (PDF albo issues w repo, jak wolisz),
• spriorytetyzowanym planem poprawek, w którym każda pozycja ma szacunek nakładu, spodziewany efekt w milisekundach (a w konwersji tam, gdzie dane pozwalają na szacunek) oraz ryzyko,
• rekomendacją go/no-go, jeśli audyt był rozpoznaniem przed większym projektem.

3. Plan (pół tygodnia, w cenie)

Ustalamy, co robimy, w jakiej kolejności i po czym poznamy, że się udało. Ten dokument staje się podstawą całej współpracy. Wszelkie rozbieżności wyjaśniamy na piśmie, zanim ruszy budowa, nie w ósmym tygodniu.

4. Budowa (tygodnie 2–N, fakturowana co tydzień)

Implementacja dzieje się w Twoim repo, na Twoim modelu branchy, w małych PR-ach, które da się rzetelnie przejrzeć. Każdą zmianę widzisz, zanim trafi do merge’a. Co tydzień dostajesz pisemne podsumowanie: co poszło na produkcję, co będzie dalej i co nas blokuje, zamiast kolejnego spotkania statusowego.

Twój wkład czasowy: jedna techniczna osoba kontaktowa, 1–2 godziny tygodniowo na review i decyzje. Może być mniej, jeśli nam ufasz, i więcej, jeśli wolisz większe zaangażowanie.

5. Cutover (ostatni tydzień, w cenie przy projektach migracyjnych)

Uruchomienie to najbardziej ryzykowna część każdej migracji, więc prowadzimy ją równolegle na shadow traffic, a nie metodą big bang. Przed przełączeniem podpisujemy pisemną checklistę go/no-go, a ścieżka rollbacku zostaje sprawna przez 30 dni. Samo przełączenie przeprowadzamy razem, na wspólnej rozmowie.

6. Utrzymanie (pierwsze 30 dni w cenie, dalej opcjonalnie)

Runbooki, monitoring, alerting, który nie generuje fałszywych alarmów, i pisemny szablon post-mortem. Po 30 dniach możesz przejąć wszystko własnym zespołem albo zostawić nas na małym retainerze do wsparcia przy incydentach i dalszego strojenia.

Co dostajesz od nas, za każdym razem

• Bezpośredni dostęp do inżynierów, którzy piszą kod, bez account managerów i warstwy „client success” po drodze. Osoba, którą widać w git blame, to ta sama osoba na Slacku.
• Zapis, na którym można się oprzeć: zakres, plan, raporty i post-mortemy lądują na piśmie, więc każda decyzja ma ślad, do którego można wrócić.
• Deploye, które da się cofnąć, i systemy, które da się odczytać. Kiedy dochodzi do awarii na produkcji, ktoś potrafi ustalić, co się stało, i wykonać rollback. Docelowo tym kimś możesz być Ty; dbamy o to, żeby to było wykonalne.

Czego oczekujemy od Ciebie

• Jednej technicznej osoby kontaktowej, która podejmuje decyzje bez zwoływania komitetu.
• Dostępów potrzebnych do pracy: repo, produkcja w trybie read-only, dashboardy usług zewnętrznych. Zwykle mniej, niż się wydaje.
• Szczerych informacji o tym, co jest zepsute, czego już próbowaliście i jakie ograniczenia polityczne wchodzą w grę. Projekt idzie szybciej, gdy nie odkrywamy tych rzeczy w trakcie budowy.

Kształt cennika

• Audyt wejściowy: za niewielką, z góry ustaloną cenę. Lighthouse, Core Web Vitals i plan trzech najważniejszych poprawek, omówione na rozmowie.
• Audyty pogłębione: stała cena, 5–10 dni roboczych zależnie od zakresu.
• Etap budowy: faktura co tydzień; typowy projekt trwa 4–16 tygodni.
• Retainery: rozliczenie miesięczne, stała liczba godzin tygodniowo, minimum trzy miesiące.

Modelu time-and-materials raczej unikamy. Tam, gdzie się da, wyceniamy stałą ceną, a tam, gdzie się nie da, pracujemy z tygodniowym limitem godzin.

---

Szablon umowy, z której naprawdę korzystamy (i na której opiera się ta strona), jest publiczny, na licencji CC. A druga połowa obietnicy: Czego nie robimy.