Hub: Software House
Software house — Web development dla firm z całej Polski. Pracujemy zdalnie, z jasnym zakresem i własnością kodu oraz dostępów po stronie klienta od pierwszego dnia.
Powiązane case studies
Ta strona zbiera to, co robimy w obszarze Web development: zakres prac, przebieg współpracy i kryteria, po których warto oceniać wykonawcę — także jeśli ostatecznie wybierzesz kogoś innego. Niżej znajdziesz też realizacje i punkty wejścia dla poszczególnych miast.
Co budujemy
Software house to nie jedna usługa, tylko kilka rodzajów pracy, które inaczej się wycenia i inaczej prowadzi. Poniżej to, co realnie robimy.
Aplikacje webowe
Od MVP, które ma zweryfikować pomysł, po platformy rozwijane latami. Przy MVP liczy się odcięcie zakresu do tego, co naprawdę sprawdza hipotezę; przy dojrzałym produkcie — architektura, która zniesie kolejne lata zmian i kolejnych programistów.
Systemy szyte na miarę
Narzędzia pod konkretny proces w firmie, którego nie obsługuje żaden gotowy produkt: obieg dokumentów, kalkulatory ofertowe, panele obsługi zgłoszeń, integracje między systemami, które nie umieją ze sobą rozmawiać. To najczęstszy powód, dla którego ktoś przychodzi do software house'u zamiast kupić gotowe oprogramowanie.
Panele administracyjne i backend
Warstwa, w której dzieje się właściwa praca: własne API, model danych, uprawnienia, obsługa błędów i stanów brzegowych. Interfejs bywa najmniejszą częścią takiego projektu, choć jest tym, co widać.
Integracje
Połączenia z systemami, które już u klienta działają — ERP, płatności, logistyka, systemy branżowe. Tu najczęściej wychodzą różnice między dokumentacją a rzeczywistością, dlatego integracje planujemy z zapasem na rozpoznanie.
Powiązane usługi
Stack
Frontend w Next.js i Reakcie, backend w Node.js, NestJS lub Pythonie, dane w PostgreSQL albo MongoDB. Nie zmieniamy stacku pod projekt bez powodu — zespół, który zna narzędzie, popełnia mniej błędów niż zespół uczący się w trakcie.
Rozwój po wdrożeniu
Oprogramowanie nie kończy się na dniu premiery: dochodzą poprawki, aktualizacje zależności, kolejne funkcje. Warto o to zapytać przed startem, bo utrzymanie bywa większym kosztem niż samo napisanie pierwszej wersji.
Jak prowadzimy projekt
Kolejność jest zawsze ta sama: najpierw ustalamy, co ma się zmienić w procesie, potem dobieramy technologię. Odwrotna kolejność kończy się narzędziem, które powstało szybciej, niż ktokolwiek ustalił, do czego ma służyć.
1. Rozpoznanie
Rozmowa o procesie, który ma zostać wsparty oprogramowaniem, o ograniczeniach technicznych i o tym, po czym poznamy, że się udało. Efektem jest zapisany zakres i lista założeń do sprawdzenia.
2. Zakres i harmonogram
Podział na etapy, z których każdy kończy się czymś działającym. Etap, którego efektu nie da się pokazać, jest dla klienta niesprawdzalny — i takich nie planujemy.
3. Iteracje
Krótkie cykle z działającym oprogramowaniem na końcu każdego. Po każdej iteracji można zmienić priorytety kolejnej — to jest sens tego trybu, nie sam rytm spotkań.
4. Testy i wdrożenie
Testy, przygotowanie środowisk, migracja danych, jeśli jest potrzebna. Wdrożenie planujemy tak, żeby dało się je wycofać.
5. Przekazanie
Dokumentacja, dostępy, omówienie architektury z osobą, która przejmie projekt. Kod, dokumentacja i dostępy należą do klienta od pierwszego dnia — nie od momentu zapłaty ostatniej faktury.
Jak wybrać software house
Oferty wyglądają podobnie, a różnice wychodzą w trzecim miesiącu. Pytania poniżej pomagają je wyciągnąć wcześniej — warto je zadać każdemu wykonawcy, nie tylko nam.
Kto konkretnie będzie pracował
Poproś o skład zespołu i o to, w jakim wymiarze te osoby są dostępne. Sytuacja, w której na rozmowie jest ktoś doświadczony, a projekt trafia do kogoś innego, jest częsta i łatwa do uniknięcia jednym pytaniem.
Co się stanie, gdy zakres się zmieni
Zmiana zakresu w trakcie to norma, nie awaria. Ustal, jak jest wyceniana i kto decyduje — brak tej ustalonej ścieżki jest częstszym źródłem konfliktu niż sama cena.
Czyj jest kod i dostępy
Repozytorium, infrastruktura, domeny, konta w usługach zewnętrznych. Warto to zapisać na początku; przy zmianie wykonawcy to właśnie tutaj pojawiają się największe problemy.
Jak wygląda utrzymanie po wdrożeniu
Kto poprawia błędy, w jakim czasie reakcji, co dzieje się z aktualizacjami zależności. Projekt bez ustalonego utrzymania zaczyna się psuć po kilku miesiącach, choć nikt go nie ruszał.
Czy wykonawca mówi „nie"
Powiązane branże
Wykonawca, który na każdy pomysł odpowiada „da się", albo nie rozumie problemu, albo nie zamierza go kwestionować. Jedno i drugie kończy się tym samym.
Czy widzisz kod i postęp w trakcie
Dostęp do repozytorium i do środowiska testowego od początku. Postęp opisany wyłącznie w procentach na spotkaniu nie jest postępem, który da się sprawdzić.
Wybrane realizacje
Zamiast opisywać kompetencje ogólnikami, pokazujemy wdrożenia — z problemem, który był na wejściu, i tym, co się zmieniło:
Pełna lista jest na stronie case studies.
Dlaczego pracujemy zdalnie
Nie prowadzimy oddziałów w poszczególnych miastach i nie udajemy, że jest inaczej. Pracujemy zdalnie z klientami z całej Polski — proces, komunikacja i tempo są takie same niezależnie od odległości. Spotkania na żywo organizujemy wtedy, gdy naprawdę coś zmieniają: warsztat otwierający, przegląd większego etapu, rozmowa z szerszym zespołem po stronie klienta. Odpowiadamy w ciągu 24 godzin.
Od czego zacząć
Najwięcej o samej usłudze — zakresie, procesie i technologiach — znajdziesz na stronie web development. Jeśli wolisz zacząć od rozmowy, napisz do nas — odpowiadamy w ciągu 24 godzin.
Działamy w całej Polsce
Pracujemy zdalnie z klientami z całej Polski — proces, komunikacja i tempo nie zależą od odległości. Wybierz miasto, aby zobaczyć, jak wygląda współpraca z nami jako software house w Twojej okolicy.
FAQ
Najczęstsze pytania
- W obu — wybór zależy od tego, jak domknięty jest zakres. Przy jasno opisanym, zamkniętym projekcie wyceniamy całość z góry i rozliczamy się w stałej kwocie. Przy produkcie, który będzie się zmieniał w trakcie, rozliczamy faktycznie przepracowany czas, bo wycena z góry musiałaby zawierać zapas na nieznane — i klient zapłaciłby za ten zapas niezależnie od tego, czy zostanie wykorzystany. Który model ma sens u Ciebie, ustalamy na pierwszej rozmowie, zanim cokolwiek wycenimy.
- Projekt prowadzi project manager i to on odpowiada za terminy, zakres i komunikację. Nie jest jednak jedynym kontaktem — pracujemy na wspólnym kanale, na którym masz bezpośredni dostęp do osób piszących kod. Nie ma sytuacji, w której pytanie techniczne wędruje przez pośrednika i wraca po dwóch dniach.
- Tak. Kod, repozytorium, dostępy do infrastruktury i konta w usługach zewnętrznych należą do Ciebie od pierwszego dnia, a nie po odbiorze albo po zapłacie ostatniej faktury. Możesz w każdej chwili zabrać projekt do siebie albo do innego wykonawcy.
- Tak, ale zaczynamy od audytu kodu i infrastruktury. Bez niego nie da się uczciwie powiedzieć, ile potrwa pierwsza zmiana ani co da się bezpiecznie ruszyć — a wycena zrobiona w ciemno kończy się rozczarowaniem po obu stronach. Audyt kończy się listą tego, co zastaliśmy, i rekomendacją: co naprawić od razu, co przepisać, a co zostawić.