Wysyłasz wiadomość z opisem projektu i w ciągu godziny ktoś odpisuje. Ten tekst opisuje wszystko, co dzieje się potem: kto co robi na każdym etapie, jakie decyzje są po Twojej stronie, co dostajesz na koniec i w których miejscach projekty naprawdę tracą czas.
Każdy projekt, od landing page po system z panelem i integracjami, przechodzi przez te same siedem etapów. Różni się ich długość, nie kolejność. Skrócona wersja jest na stronie Jak pracujemy, a tutaj rozpisujemy ją ze szczegółami, których na stronie nie ma miejsca pokazać.
Opisujesz, co ma powstać, a my wracamy z pytaniami, widełkami i wstępnym zakresem.
Dostajesz konto, w którym widać harmonogram, pliki, rozliczenia i zgłoszenia.
Układ i przepływ kluczowych ekranów, zanim powstanie pierwsza linijka kodu.
Praca na stagingu i we wspólnym repozytorium, z raportami postępu.
Lista kontrolna przed wdrożeniem i zapas czasu na korekty wliczony w cenę.
Start w ustalonym terminie, repozytorium, dokumentacja i dostępy po Twojej stronie.
Monitoring i zgłoszenia w tym samym panelu, w którym prowadziliśmy projekt.
Pierwsza wiadomość: co napisać, żeby odpowiedź była konkretna
Pierwsza wiadomość nie musi być specyfikacją. Wystarczy, że odpowiada na trzy pytania, które i tak zadamy w odpowiedzi: co ma powstać, dla kogo i co się stanie, jeśli tego nie zbudujesz. Ostatnie pytanie nie jest złośliwe. Pokazuje, czy chodzi o narzędzie, które oszczędzi zespołowi godziny pracy, o stronę, która ma przynosić zapytania, czy o pomysł, który dopiero trzeba sprawdzić na rynku. Od tej odpowiedzi zależy, czy proponujemy szybką wersję, czy dopracowany produkt.
Porównaj dwie wiadomości o tym samym projekcie:
Potrzebujemy panelu do zamówień. Ile to kosztuje?
Mamy sklep stacjonarny i przyjmujemy zamówienia hurtowe mailem. Trzy osoby przepisują je do arkusza i do programu do faktur. Chcemy panelu, w którym klient hurtowy sam składa zamówienie, a my widzimy je od razu ze statusem. Faktury wystawiamy w jednym programie, zależy nam, żeby dane tam trafiały. Termin: przed sezonem jesiennym.
Na pierwszą wiadomość odpowiemy pytaniami, na drugą widełkami i listą rzeczy do doprecyzowania. Obie są w porządku, druga po prostu skraca drogę o jedną wymianę wiadomości. Jeśli nie wiesz, jak coś opisać, napisz tak, jak opowiedziałbyś to znajomemu, bez żargonu. Tłumaczenie tego na zakres techniczny to nasza praca.
Odpowiadamy w godzinę i odpisuje osoba, która będzie pisać kod, a nie handlowiec, który przekaże pytania dalej. Na co dzień komunikujemy się przez Discorda, bo pozwala szybko wymieniać zrzuty ekranu i krótkie pytania bez długich wątków mailowych, ale pierwszy kontakt może przyjść dowolną drogą, na przykład przez formularz kontaktowy.
Wycena: najpierw widełki, potem konkretna kwota
Nie mamy sztywnego cennika ani pakietów, bo dwa projekty z tą samą nazwą, na przykład "sklep internetowy", potrafią różnić się zakresem tak bardzo, że wspólna cena nie mówiłaby nic. Publikujemy tylko ceny "od", które pokazują dolną granicę dla danego rodzaju projektu: Landing Page od 499 zł, Strona Firmowa od 1 199 zł, Panele i Dashboardy od 699 zł, Platformy Internetowe od 899 zł, Sklepy i E-commerce od 1 699 zł, Aplikacje Mobilne od 749 zł, Aplikacje Desktopowe od 999 zł, Integracje i Automatyzacje od 299 zł.
Wycena ma dwa kroki. Przy ogólnym zarysie projektu podajemy widełki, żeby było od razu jasne, czy rozmawiamy w tym samym rzędzie wielkości co Twój budżet. Konkretną kwotę podajemy dopiero po ustaleniu zakresu, terminu i wymagań, bo dopiero wtedy wiadomo, co dokładnie wyceniamy. Oba kroki są bezpłatne, tak samo jak porady na etapie, na którym jeszcze nie wiesz, czego potrzebujesz.
Wycena, którą dostajesz, zawiera listę funkcji opisanych tak, żeby dało się sprawdzić, czy zostały zrobione, termin, harmonogram płatności oraz listę rzeczy, które nie wchodzą w zakres. Ta ostatnia lista jest równie ważna jak pierwsza: jeśli teksty na stronę, zdjęcia albo opłaty za zewnętrzne usługi są po Twojej stronie, powinieneś to wiedzieć przed podpisaniem umowy, a nie w połowie projektu.
Na tym etapie zdarza się też, że mówimy "nie" albo proponujemy coś innego niż to, o co pytasz. Jeśli termin jest za krótki na pełny zakres, proponujemy mniejszą pierwszą wersję, która zdąży, i resztę w kolejnym etapie. Jeśli z rozmowy wynika, że problem da się rozwiązać gotowym narzędziem, mówimy to wprost. Wolimy powiedzieć "nie" niż obiecać coś, czego nie dowieziemy. Zero presji na szybką decyzję działa w obie strony: masz czas, żeby porównać ofertę z innymi.
Umowa, NDA i harmonogram płatności
Jeśli projekt dotyczy czegoś, czego nie chcesz pokazywać bez zabezpieczenia, podpisujemy NDA na życzenie, zanim wymienimy szczegóły. Dotyczy to zwykle pomysłów na produkt, danych klientów w przykładowych plikach i dokumentacji wewnętrznych systemów, z którymi mamy się integrować.
Umowa zamyka w jednym miejscu to, co ustaliliśmy przy wycenie: zakres, termin, kwotę i sposób odbioru. Rozliczenie dzielimy najczęściej na trzy równe części, czyli 33/33/33, przypięte do etapów projektu. Dzięki temu żadna ze stron nie ponosi całego ryzyka z góry: nie płacisz całości przed zobaczeniem efektów, a my nie pracujemy miesiącami bez rozliczenia. Momenty płatności zapisujemy w umowie razem z tym, co musi być gotowe, żeby dana część stała się wymagalna.
W cenie jest zapas na poprawki równy 15% czasu projektu. To nie jest dodatek naliczany później, tylko czas zaplanowany z góry na korekty, które wychodzą przy testach i w pierwszym okresie po starcie. Więcej o tym, co się w nim mieści, piszemy w sekcji o testach.
Umowa określa też, co dzieje się z kodem. Po zakończeniu projektu dostajesz pełne prawa do kodu i dokumentację, która pozwala przejąć go innemu zespołowi. Zapisujemy to od razu, bo to decyzja, która ma znaczenie za kilka lat, gdy będziesz rozwijać system, a nie w dniu podpisania.
Onboarding w panelu klienta
Po podpisaniu umowy dostajesz konto w panelu klienta. To miejsce, w którym projekt jest widoczny dla obu stron od pierwszego dnia, na prawdziwych danych, a nie w postaci obietnicy, że "na koniec wszystko pokażemy".
W panelu znajdziesz kilka widoków, z których każdy odpowiada na inne pytanie:
- Pulpit - status etapów, ostatnie zdarzenia i to, co czeka na Twoją decyzję.
- Moje projekty - każde zlecenie z harmonogramem, kamieniami milowymi i linkami do stagingu oraz repozytorium.
- Ogłoszenia - zmiany i rzeczy do potwierdzenia zebrane w jednym miejscu, zamiast rozproszonych po skrzynce.
- Rozliczenia - faktury, płatności i budżet projektu w jednym widoku.
- Wsparcie - zgłoszenia i pytania, które zostają przy projekcie, z pełną historią.
- Ustawienia - dane konta, dostępy dla osób z Twojego zespołu i powiadomienia.
Onboarding to też moment, w którym po Twojej stronie jest najwięcej do zrobienia. Potrzebujemy dostępów, których nie da się wygenerować za Ciebie: do domeny, do istniejącego hostingu, do kont w zewnętrznych usługach, z którymi projekt ma się łączyć. Potrzebujemy też materiałów: logo, identyfikacji wizualnej, tekstów, zdjęć, przykładowych danych. Każda z tych rzeczy, która przyjdzie później, przesuwa wszystko, co od niej zależy.
Najważniejsza decyzja organizacyjna tego etapu to wskazanie jednej osoby, która po Twojej stronie akceptuje prototyp i odbiera kolejne etapy. Może konsultować się z kim chce, ale ostateczne "tak" powinno przychodzić z jednego miejsca. Projekt, w którym trzy osoby dają sprzeczne uwagi do tego samego ekranu, stoi, dopóki nie ustalą między sobą wersji.
Prototypowanie interfejsu: najtańszy moment na zmianę zdania
Zanim powstanie kod, widzisz układ i przepływ kluczowych ekranów w formie wireframe'ów. To uproszczone szkice, na których nie ma jeszcze kolorów ani ostatecznej typografii. Rozmawiamy o tym, gdzie stoi przycisk, w jakiej kolejności czyta się sekcje i ile kroków dzieli użytkownika od celu.
To, co prototypujemy, zależy od rodzaju projektu:
| Rodzaj projektu | Na czym skupia się prototyp |
|---|---|
| Strona firmowa | Układ, hierarchia treści i ścieżka do kontaktu, zanim ruszy grafika |
| Panel i dashboard | Nawigacja, tabele i widoki danych rozrysowane tak, jak będą używane na co dzień |
| Sklep | Karta produktu, koszyk i checkout, z kolejnością kroków ustaloną z góry |
| Aplikacja mobilna | Wersje na telefon projektowane równolegle, a nie doklejane na końcu |
Ten etap istnieje z jednego powodu: zmiana na szkicu kosztuje godziny, a ta sama zmiana w gotowym kodzie potrafi kosztować tygodnie. Przesunięcie sekcji na wireframie to kilka minut pracy. Przesunięcie jej po tym, jak powstały pod nią komponenty, dane i wersja mobilna, oznacza przebudowę kilku warstw naraz.
Przeglądając prototyp, nie oceniaj go jak gotowej strony. Zadaj sobie inne pytania: czy każdy ekran ma dane, które naprawdę posiadasz, czy każda ścieżka kończy się konkretną akcją, co widzi użytkownik, gdy lista jest pusta albo formularz zwróci błąd. Uwagi o kolorach i zdjęciach zanotuj na później, bo wrócą na etapie projektu graficznego i budowy.
Akceptacja prototypu oznacza zamrożenie układu. Nie znaczy to, że nic już nie może się zmienić, ale każda zmiana układu po tym momencie jest traktowana jako zmiana zakresu, z opisanym wpływem na termin i kwotę. Dlatego lepiej poświęcić na prototyp o dzień dłużej niż zaakceptować go w pośpiechu.
Tworzenie oprogramowania: staging i repozytorium od pierwszego dnia
Budowa toczy się na stagingu, czyli testowej wersji projektu dostępnej pod osobnym adresem, i we wspólnym repozytorium. Dostęp do obu masz od początku, a nie dopiero przy odbiorze. Możesz w każdej chwili otworzyć staging i zobaczyć, jak projekt wygląda dziś, albo zajrzeć do repozytorium i sprawdzić, co zmieniło się od wczoraj.
Produkt rośnie fazami i dobrze jest wiedzieć, jak wyglądają, żeby nie zgłaszać jako błędów rzeczy, które są celowo niedokończone. Przykładowy rytm dla projektu z panelem wygląda tak:
Routing, model danych i struktura aplikacji. Pusta, ale działająca konstrukcja.
Widoki rozstawione według zaakceptowanego prototypu, z tymczasowymi danymi i tekstami.
Interfejs zaczyna pokazywać to, co będzie w nim na produkcji.
Połączenia z zewnętrznymi systemami, wykresy, obsługa błędów i dopracowane wersje mobilne.
Liczba i długość faz zależą od zakresu. Mały landing page może przejść przez nie w kilka dni, system z kilkoma integracjami potrzebuje na każdą z nich więcej czasu. Stała jest kolejność i to, że każdą fazę widzisz na stagingu w momencie, w którym powstaje, a wersje na desktop i telefon rosną równolegle.
Raporty postępu dostajesz bez proszenia: krótkie podsumowanie tego, co zostało zrobione, co jest w toku i czy coś czeka na Twoją decyzję. Nie musisz pytać, na czym stoimy. Krótkie pytania w trakcie, na przykład o treść komunikatu błędu albo kolejność pól w formularzu, zadajemy na Discordzie, a sprawy, które mają zostać w historii projektu, trafiają do panelu.
Tempo ustalamy pod Ciebie. Jeśli potrzebujesz działającej wersji jak najszybciej, żeby sprawdzić pomysł na użytkownikach, budujemy MVP i świadomie odkładamy dopracowanie szczegółów. Jeśli projekt ma od razu wyglądać i działać bez kompromisów, planujemy więcej czasu na dopracowanie. Obie drogi są uczciwe, byle było jasne od początku, którą idziemy.
Zmiany w trakcie projektu: poprawka czy nowy zakres
W prawie każdym projekcie w trakcie budowy pojawia się pomysł, którego nie było w zakresie. To normalne, bo dopiero działająca wersja na stagingu pokazuje rzeczy, których nie widać na szkicu. Ważne jest, żeby obie strony tak samo rozumiały, kiedy zmiana jest poprawką, a kiedy nowym zakresem.
Poprawka to sytuacja, w której coś działa inaczej, niż ustaliliśmy, albo wymaga drobnej korekty w ramach tego, co już jest: literówka, źle ustawiony odstęp, pole formularza, które powinno być wymagane, komunikat, który brzmi niejasno. Zmiana zakresu to coś nowego albo przebudowa czegoś zaakceptowanego: dodatkowy widok, nowa integracja, zmiana układu po akceptacji prototypu, nowa rola użytkownika z własnymi uprawnieniami.
| Zgłoszenie | Rodzaj | Co się dzieje |
|---|---|---|
| Przycisk wysyła formularz bez wymaganego pola | Poprawka | Naprawiamy w ramach projektu |
| Komunikat o błędzie jest niezrozumiały | Poprawka | Zmieniamy treść w ramach projektu |
| Tabela powinna mieć dodatkową kolumnę z danymi, które już są w bazie | Zależy od skali | Zwykle mieści się w zapasie na poprawki |
| Nowy raport dla zarządu z osobnymi filtrami | Zmiana zakresu | Opisujemy wpływ na termin i kwotę, Ty decydujesz |
| Integracja z drugim programem do faktur | Zmiana zakresu | Osobna wycena przed rozpoczęciem prac |
Przy zmianie zakresu nie zaczynamy pracy, zanim nie dostaniesz opisu jej wpływu na termin i kwotę. Możesz ją przyjąć, przesunąć do kolejnego etapu po starcie albo z niej zrezygnować. Dzięki temu na koniec projektu nie ma zaskoczenia w postaci faktury za rzeczy, o których koszcie nikt nie rozmawiał.
Zapas na poprawki równy 15% czasu projektu jest po to, żeby granica między poprawką a zmianą nie była polem sporu przy każdym drobiazgu. Drobne rzeczy, które wychodzą w praktyce, robimy bez liczenia minut, a rozmowa o zakresie zaczyna się dopiero przy zmianach, które realnie wpływają na harmonogram.
Testy i bufor na poprawki
Przed wdrożeniem projekt przechodzi przez listę kontrolną, którą budowaliśmy latami po to, żeby nie popełniać dwa razy tego samego błędu. Obejmuje sześć obszarów:
| Obszar | Co sprawdzamy |
|---|---|
| Ścieżki krytyczne | Rejestracja, płatność, wysyłka formularza, przeklikane ręcznie od początku do końca |
| Responsywność | Szerokości od 360 px w górę, na realnych treściach, a nie na tekście zastępczym |
| Wydajność | Core Web Vitals mierzone na buildzie produkcyjnym, a nie na wersji deweloperskiej |
| Dostępność | Kontrast, nawigacja klawiaturą, sensowne etykiety pól i przycisków |
| Stany błędów | Co widzi użytkownik, gdy coś pójdzie nie tak: brak sieci, pusta lista, błędne dane |
| Bezpieczeństwo | Walidacja danych, uprawnienia i ochrona formularzy przed nadużyciem |
Przy wydajności punktem odniesienia są progi, które Google publikuje dla Core Web Vitals: czas wyrenderowania największego elementu (LCP) poniżej 2,5 sekundy, reakcja na interakcję (INP) poniżej 200 milisekund i przesunięcia układu (CLS) poniżej 0,1. Mierzymy je na buildzie produkcyjnym, bo wersja deweloperska zachowuje się inaczej i jej wyniki niczego nie dowodzą.
Równolegle z naszymi testami Ty sprawdzasz projekt na stagingu z własnej perspektywy. Nie musisz powtarzać naszej listy. Najcenniejsze są scenariusze, które znasz tylko Ty: prawdziwy klient z nietypowym zamówieniem, dane, które w Twojej branży wyglądają inaczej niż w przykładach, telefon, na którym pracuje Twój zespół. Uwagi zgłaszasz w panelu, gdzie każda ma swój status i historię.
Po testach zostaje zapas na poprawki wliczony w cenę, czyli 15% czasu projektu. Obejmuje korekty, które wychodzą przy odbiorze i w pierwszym okresie po starcie, gdy projekt spotyka się z prawdziwymi użytkownikami. Nie wystawiamy osobnej faktury za każdą literówkę i każdy źle wyrównany element.
Wdrożenie i przekazanie kodu
Termin wdrożenia ustalamy razem, tak żeby nie zaskoczył Twoich użytkowników ani zespołu. Wdrażamy raczej w środku dnia roboczego, kiedy obie strony są dostępne i ewentualny problem można rozwiązać od razu, a nie w piątek wieczorem, gdy wszyscy są już offline. Jeśli projekt zastępuje istniejący system albo stronę, wcześniej ustalamy, co dzieje się ze starymi adresami, danymi i kontami użytkowników.
Dzień startu ma kilka technicznych szczegółów, o których dobrze wiedzieć wcześniej. Zmiana rekordów DNS domeny nie działa u wszystkich użytkowników w tej samej minucie, bo serwery pośrednie pamiętają poprzednie wartości przez czas zapisany w parametrze TTL, dlatego ten czas obniża się z wyprzedzeniem. Jeśli nowa strona zmienia adresy podstron, stare adresy dostają przekierowania 301 na nowe odpowiedniki, żeby nie zgubić linków z wyszukiwarki i od partnerów. Jeśli z domeny wysyłana jest poczta, sprawdzamy, czy zmiana nie narusza jej rekordów.
Po starcie dostajesz wszystko, co składa się na projekt:
- Repozytorium - z pełną historią zmian, przeniesione na Twoje konto.
- Dokumentacja - jak uruchomić projekt, jak go wdrożyć i gdzie znajdują się poszczególne części.
- Dostępy - serwer, domena i usługi zewnętrzne zarejestrowane na Ciebie, a nie na nas.
- Przekazanie na żywo - rozmowa, na której przechodzimy przez projekt z Twoim zespołem i odpowiadamy na pytania.
Kod jest Twój i nie jest zakładnikiem naszej firmy. Masz do niego pełne prawa, a dokumentacja jest pisana tak, żeby inny zespół mógł go przejąć bez dzwonienia do nas. Jeśli za rok zdecydujesz, że dalszy rozwój poprowadzi ktoś inny albo Twój własny programista, nie musisz nas o nic prosić.
To podejście ma też praktyczny skutek dla nas: skoro zakładamy, że ktoś inny może przeczytać ten kod, piszemy go tak, żeby dało się go przeczytać. Repozytorium, które przez cały projekt było dostępne dla klienta, nie ma zakamarków, których nikt nie miał zobaczyć.
Wsparcie po starcie i monitoring
Premiera nie kończy współpracy. Po wdrożeniu monitorujemy dostępność i czas odpowiedzi projektu, najczęściej przez 90 dni bez dodatkowych opłat. Jeśli coś przestaje działać, zwykle wiemy o tym, zanim zgłosi to pierwszy użytkownik.
Zgłoszenia po starcie trafiają do tego samego panelu, w którym prowadziliśmy projekt. Nikt nie zaczyna rozmowy od zera i nie musi odtwarzać kontekstu, bo cała historia ustaleń, testów i poprawek jest w jednym miejscu. Pytanie o cokolwiek dotyczącego projektu nic nie kosztuje.
Po okresie monitoringu dalsza opieka zależy od projektu. Strona firmowa, której treść zmienia się rzadko, potrzebuje innego wsparcia niż sklep albo panel, z którego zespół korzysta codziennie. Zakres opieki, czas reakcji i ewentualne warunki dostępności ustalamy indywidualnie w umowie, adekwatnie do tego, jak bardzo biznes zależy od działania systemu.
Pierwsze tygodnie po starcie to też dobry moment na zebranie listy rzeczy do kolejnego etapu. Zmiany zakresu, które odłożyliśmy w trakcie budowy, i obserwacje z prawdziwego użytkowania dają zwykle konkretniejszy materiał do planowania niż jakakolwiek rozmowa przed startem.
Gdzie projekty naprawdę zwalniają
Większość opóźnień nie wynika z tego, że kod okazał się trudniejszy, niż zakładano. Wynika z rzeczy, które czekają na decyzję albo materiał i przez kilka dni nikt nie zauważa, że cały etap stoi. Opisujemy je wprost, bo część z nich jest po naszej stronie, a część po Twojej, i obie łatwiej kontrolować, gdy się o nich wie z góry.
| Blokada | Skutek | Jak jej uniknąć |
|---|---|---|
| Brak jednej osoby decyzyjnej | Sprzeczne uwagi do tego samego ekranu, praca w kółko | Wskazać osobę akceptującą przy onboardingu |
| Teksty i zdjęcia przychodzą na końcu | Ekrany czekają na zaślepkach, testy na realnych treściach się przesuwają | Ustalić termin materiałów w harmonogramie jak każdy inny etap |
| Dostępy do zewnętrznych usług | Integracja gotowa po naszej stronie, ale nie da się jej uruchomić | Założyć konta i zebrać klucze na etapie onboardingu |
| Weryfikacja u operatora płatności | Sklep gotowy, płatności nieaktywne | Rozpocząć weryfikację konta u operatora na starcie projektu, bo trwa po jego stronie |
| Zmiana układu po akceptacji prototypu | Przebudowa kilku warstw, przesunięcie terminu | Poświęcić więcej czasu na prototyp, zmiany zgłaszać jako osobny zakres |
| Uwagi rozproszone po mailach, czacie i telefonie | Zgłoszenia giną albo są realizowane dwa razy | Wszystko, co ma zostać w historii, zgłaszać w panelu |
Po naszej stronie ryzykiem, którego nie da się wykluczyć na etapie wyceny, jest integracja z systemem, którego dokumentacja nie odpowiada rzeczywistości. Gdy to wychodzi, mówimy od razu, co to znaczy dla terminu, zamiast próbować nadrobić to po cichu kosztem testów. Raport postępu, w którym pojawia się informacja o problemie, jest cenniejszy niż taki, w którym wszystko zawsze idzie zgodnie z planem.
Najprostszym zabezpieczeniem przed większością tych blokad jest termin odpowiedzi zapisany przy każdym etapie, który wymaga Twojej decyzji. Opóźniona akceptacja rzadko przesuwa wdrożenie dokładnie o tyle dni, o ile się spóźniła, bo po jej nadejściu trzeba jeszcze odzyskać miejsce w harmonogramie i wrócić do kontekstu. Pulpit w panelu klienta pokazuje rzeczy czekające na Twoją decyzję właśnie po to, żeby nie leżały niezauważone między innymi wiadomościami.
Jeśli masz projekt, który chcesz przeprowadzić przez te etapy, napisz do nas przez formularz kontaktowy. Wróci do Ciebie osoba, która będzie go budować, z pytaniami i widełkami, a ceny startowe poszczególnych rodzajów projektów znajdziesz na stronie z ofertami.
