Software house dla firm B2B – jak wybrać partnera do rozwoju systemu

Dobry software house dla firm B2B poznasz po tym, że zanim poda cenę, chce zrozumieć Twoje procesy: jak liczycie ceny dla klientów, gdzie są dane o towarach i stanach, kto zatwierdza zamówienia i co dzieje się, gdy ERP jest niedostępny. Drugi sprawdzian to sposób pracy – czy dostaniesz dostęp do repozytorium, regularne wydania i jasny obraz postępów, czy tylko obietnicę terminu. Trzeci to umowa: prawa do kodu, odpowiedzialność za dane i zasady utrzymania po wdrożeniu. Poniżej rozpisujemy te obszary na konkretne pytania i sygnały ostrzegawcze.

Zacznij od własnej listy, nie od listy firm

Najczęstszy błąd przy wyborze wykonawcy to wysłanie zapytania do kilku firm z jednym zdaniem opisu i porównywanie odpowiedzi po cenie. Wyceny różnią się wtedy kilkukrotnie, bo każda firma zakłada inny zakres. Zanim zaczniesz rozmowy, przygotuj:

• cel biznesowy – co ma się zmienić po wdrożeniu, np. klienci składają zamówienia sami zamiast przez maila,
• użytkowników – kto będzie korzystał z systemu: klienci, handlowcy, magazyn, administracja,
• systemy, z którymi trzeba się połączyć – ERP, CRM, sklep, kurierzy, księgowość, wraz z informacją, czy mają API,
• ograniczenia – termin, który wynika z realnego powodu, budżet na pierwszy etap, wymagania bezpieczeństwa.

Jak ująć to w dokumencie, który da się rzetelnie wycenić, opisujemy w artykule Jak opisać wymagania do aplikacji webowej.

Co sprawdzić w doświadczeniu

Portfolio pełne ładnych stron internetowych niewiele mówi o umiejętności budowy systemu B2B. Szukaj projektów, które mają podobne cechy do Twojego:

• integracje z ERP lub innymi systemami firmowymi – zapytaj, jak rozwiązano obsługę błędów i co się dzieje, gdy druga strona nie odpowiada,
• logika cenowa i uprawnienia – cenniki per klient, rabaty, role użytkowników w firmie klienta,
• rozwój systemu przez lata, a nie jednorazowe wdrożenie – to pokazuje, czy kod da się utrzymać,
• modernizacja istniejących aplikacji, jeśli Twój obecny system ma zostać przepisany lub rozbudowany.

Poproś o rozmowę o jednym projekcie w szczegółach: jaki był problem, jak wyglądała architektura, co poszło nie tak i jak to naprawiono. Firma, która potrafi uczciwie opowiedzieć o trudnościach, zwykle lepiej radzi sobie z nimi w kolejnych projektach.

Technologia: dopasowanie, nie moda

Dla większości systemów B2B – portali klienta, platform zamówień, CRM, paneli administracyjnych – sprawdzają się dojrzałe technologie webowe. W naszym przypadku to PHP z Laravel po stronie serwera oraz Vue.js lub React w interfejsie. Ważniejsze od samej nazwy frameworka są jednak trzy rzeczy:

1. Aktualne wersje. Nowy projekt powinien startować na wspieranej wersji PHP (dziś 8.3 lub 8.4) i aktualnym wydaniu frameworka. PHP 8.1 i starsze nie mają już wsparcia bezpieczeństwa.
2. Popularność na rynku. System ma żyć latami. Jeśli za trzy lata zmienisz wykonawcę, nowy zespół musi być w stanie przejąć kod.
3. Spójność z tym, co już masz. Jeśli inne systemy w firmie są napisane w danej technologii, wspólny stos ułatwia utrzymanie.

Podejrzliwie podchodź do propozycji mikroserwisów, własnych frameworków czy egzotycznych baz danych przy pierwszym etapie średniej wielkości systemu. To zwykle zwiększa koszt i uzależnia od jednego wykonawcy.

Wielkość zespołu a skala projektu

Duża firma daje większą odporność na urlopy i rotację, ale Twój projekt może być dla niej jednym z wielu i trafić do zespołu, który zmienia się co kilka miesięcy. Mały software house bywa bliżej problemu i szybciej podejmuje decyzje, za to trzeba sprawdzić, czy ma zastępstwo dla kluczowych osób. Niezależnie od skali zapytaj, ile osób będzie znało Twój system na tyle dobrze, żeby usunąć awarię w piątek wieczorem. Dla systemu, od którego zależą zamówienia, odpowiedź „jedna” jest niewystarczająca.

Sposób pracy – pytania na drugie spotkanie

To, jak firma pracuje na co dzień, decyduje o powodzeniu projektu bardziej niż technologia. Zapytaj wprost:

• Kto konkretnie będzie pracował nad projektem? Poproś o rozmowę z osobą prowadzącą technicznie, nie tylko z handlowcem.
• Jak wygląda analiza przed wyceną? Czy jest osobnym, płatnym etapem z konkretnym wynikiem: mapą procesu, listą integracji, zakresem pierwszego etapu?
• Jak często zobaczę działającą wersję? Dobrą praktyką są wydania na środowisko testowe co tydzień lub dwa.
• Gdzie jest kod? Najlepiej w repozytorium należącym do klienta albo z pełnym dostępem od pierwszego dnia.
• Jak testujecie? Automatyczne testy kluczowych procesów, środowisko testowe z danymi zbliżonymi do produkcyjnych, powtarzalne wdrożenia.
• Jak zgłaszam zmianę zakresu? Każda zmiana powinna mieć wycenę i wpływ na termin, zanim zostanie wykonana.

Umowa: na co zwrócić uwagę

Umowa z software house to nie formalność. Kluczowe zapisy:

• Prawa autorskie. Przeniesienie autorskich praw majątkowych do kodu musi wymieniać pola eksploatacji i mieć formę pisemną. Sprawdź też, jak potraktowano biblioteki open source i komponenty, których wykonawca używa w wielu projektach – te zwykle obejmuje licencja, nie przeniesienie praw.
• Dane osobowe. Jeśli wykonawca ma dostęp do danych klientów, potrzebna jest umowa powierzenia przetwarzania zgodna z art. 28 RODO.
• Model rozliczenia. Ryczałt na dobrze opisany etap albo czas pracy z budżetem i raportami. Unikaj ryczałtu na cały, nieopisany system – ryzyko wraca potem w postaci sporów o zakres.
• Odbiory i gwarancja. Jak wygląda odbiór etapu, ile trwa okres naprawy błędów bez dodatkowych kosztów.
• Utrzymanie po wdrożeniu. Czas reakcji na awarie, aktualizacje bezpieczeństwa, zasady rozwoju.
• Wyjście z umowy. Przekazanie kodu, dokumentacji i dostępów w razie zakończenia współpracy.

O tym, od czego zależy budżet i jak czytać wyceny, piszemy w tekście Ile kosztuje dedykowana aplikacja webowa.

Sygnały ostrzegawcze

• Wycena całego systemu po jednym spotkaniu, bez analizy.
• Brak pytań o integracje, dane i procesy – rozmowa tylko o wyglądzie.
• Niechęć do udostępnienia repozytorium w trakcie projektu.
• Obietnica terminu, który nie uwzględnia testów z użytkownikami ani migracji danych.
• Jeden człowiek odpowiadający za wszystko, bez zastępstwa.
• Umowa, w której prawa do kodu przechodzą dopiero po zapłacie za całość wieloletniego rozwoju.

Jak przeprowadzić wybór krok po kroku

1. Przygotuj opis celu, użytkowników i systemów – jedna, dwie strony wystarczą.
2. Wybierz trzy firmy na podstawie projektów podobnych do Twojego.
3. Przeprowadź rozmowy z osobami technicznymi i porównaj, jakie pytania padły.
4. Zamów płatną analizę u jednej lub dwóch firm. Jej wynik – mapa procesu, architektura, zakres pierwszego etapu – należy do Ciebie niezależnie od dalszej decyzji.
5. Zacznij od etapu, który sam daje wartość, np. katalog i zamówienia dla wybranej grupy klientów. Po nim wiesz, jak się współpracuje, zanim zaangażujesz większy budżet.

Następny krok

Spisz na jednej stronie cel projektu, listę użytkowników i systemów do integracji, a potem z tą kartką porozmawiaj z dwoma lub trzema wykonawcami. Już po pierwszych rozmowach zobaczysz, kto pyta o procesy, a kto od razu o ekrany. Jeśli szukasz zespołu, który buduje i rozwija systemy B2B w Laravel, zajrzyj na stronę software house Laravel albo napisz do nas – zaczniemy od rozmowy o Twoim procesie. Pracujemy zdalnie z firmami z całej Polski – opisy współpracy dla największych miast znajdziesz na stronach software house Warszawa, Kraków, Łódź i Wrocław.