Software House Szczecin

Firmy ze Szczecina szukające wykonawcy w obszarze Web development zwykle stają przed tym samym pytaniem: wybrać kogoś na miejscu czy zespół, który zna daną klasę problemów. Pracujemy zdalnie i nie traktujemy tego jako kompromisu — proces prowadzimy identycznie niezależnie od lokalizacji klienta. Poniżej opisujemy, co dokładnie wchodzi w zakres, jak wygląda współpraca i na co zwracać uwagę przy wyborze wykonawcy, także jeśli ostatecznie wybierzesz kogoś innego.

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.

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"

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 konkretne wdrożenia — z problemem, który był na wejściu, i tym, co się zmieniło:

• papierowa dokumentacja TSL zastąpiona aplikacją z e-podpisem
• poland-build

Pełna lista jest na stronie case studies.

Współpraca zdalna z firmami ze Szczecina

Nie mamy biura w Szczecinie i nie udajemy, że mamy. Pracujemy zdalnie z klientami z całej Polski i prowadzimy projekt tak samo niezależnie od tego, gdzie jest klient — ten sam proces, te same etapy, ta sama częstotliwość kontaktu.

Komunikację prowadzimy w kanale, który wybiera klient: spotkania online, wspólna tablica, podsumowanie po każdej iteracji. 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.

Co się z tym łączy

Produkty, które dostarczamy w ramach tej usługi: strona internetowa, sklep internetowy, platforma SaaS, system CMS.

Branże, w których ta usługa pojawia się najczęściej: finanse i FinTech, logistyka i LogTech, edukacja i EdTech.

Pokrewne kompetencje: projektowanie UX na etapie przed developmentem. Później dochodzi pozycjonowanie, gdy gotowy produkt ma zdobywać ruch organiczny.

Czego jeszcze możesz potrzebować przy projekcie

Sam kod to zwykle nie koniec projektu — po starcie trzeba zadbać o widoczność produktu i o to, żeby wygodnie się z niego korzystało. Ten sam zespół, który pisze kod, prowadzi też projektowanie interfejsów — projekt nie przechodzi między firmami.

O tym, jak prowadzimy projekty i jak wygląda u nas współpraca, piszemy na stronie software house. Zakres samej usługi opisujemy osobno — na stronie web development. Masz konkretny projekt w głowie? Napisz do nas — odpowiadamy w ciągu 24 godzin.