Pytania, które padają przed podpisaniem umowy

Umowę B2B między naszymi firmami, rozliczaną fakturą VAT. Jej forma zależy od modelu rozliczenia: przy stałej cenie za etap to umowa o wykonanie oprogramowania, przy rozwoju ciągłym — umowa o świadczenie usług. Reguluje zakres, harmonogram, warunki płatności i przeniesienie na Ciebie autorskich praw majątkowych.

Z chwilą zapłaty za dany etap, a nie na końcu projektu. Oznacza to, że po każdej opłaconej iteracji jesteś właścicielem tego, co powstało, i przerwanie współpracy nie zostawia Cię z niczym.

Tak, standardowo przed pierwszą rozmową o szczegółach, jeśli tego potrzebujesz. Akceptujemy też Wasz wzór — nie mamy w tym zakresie własnych wymagań poza tym, żeby był wzajemny.

Wycena podana na starcie zawiera założenia, na których stoi. Jeśli któreś przestanie obowiązywać, dostajesz aneks z wyceną tej konkretnej zmiany, zanim zaczniemy nad nią pracować. Nie ma niespodzianek na fakturze, bo nie ma pozycji, o której nie było rozmowy.

Tak. Działamy jako spółka z ograniczoną odpowiedzialnością wpisana do KRS, z numerami NIP i REGON — pełne dane rejestrowe są w stopce tej strony.

Twoje, od pierwszego dnia. Zakładamy je na Twoje dane i dostajemy do nich dostęp, a nie odwrotnie. Nie ma więc momentu „migracji od wykonawcy" — jest tylko odebranie nam uprawnień.

Nie. Budujemy na powszechnie dostępnych, otwartych technologiach, wypisanych na stronie technologii. Zamknięty silnik wykonawcy jest najskuteczniejszym mechanizmem uzależniającym, jaki znamy, i dlatego go nie stosujemy.

Domyślnie nikt z nas. Pracujemy na danych testowych, a dostęp produkcyjny jest imienny, ograniczony w czasie i przyznawany tylko wtedy, gdy jest potrzebny do zdiagnozowania konkretnego problemu. Jeśli macie własną politykę dostępu, pracujemy według niej.

Przy przetwarzaniu danych osobowych podpisujemy umowę powierzenia. Projektując system, pytamy, które dane są naprawdę potrzebne — bo najtańszym sposobem na zgodność jest nie zbierać danych, których się nie używa.

To jeden z warunków, które sami sobie stawiamy. Dokumentacja i testy powstają tak, żeby inny zespół mógł przejąć system bez naszego udziału i bez naszej zgody. Uważamy, że wykonawca, którego nie da się zmienić, ma zbyt silną pozycję, żeby współpraca była uczciwa.

Jesteśmy małym zespołem i celowo tacy zostajemy. W praktyce oznacza to, że osoba z pierwszego spotkania jest tą, która pisze kod, a nie handlowcem przekazującym projekt dalej. Przy większym zakresie skład ustalamy imiennie na warsztacie.

Nie w modelu, w którym projekt trafia do nieznanego Ci podwykonawcy. Jeśli projekt wymaga kompetencji, których nie mamy — mówimy to i albo wskazujemy kogoś, kto je ma, albo ustalamy jego udział jawnie, z nazwiskiem.

Wspólny kanał komunikacji i dostęp do środowiska testowego od pierwszego dnia. Potrzebujemy jednej osoby decyzyjnej po Waszej stronie z około dwiema godzinami w miesiącu — nie na nadzór nad kodem, tylko na rozstrzyganie pytań o to, jak działa Wasza firma.

Zdalnie, z siedzibą w Warszawie. Na warsztat discovery przyjeżdżamy, jeśli ma to sens — przy mapowaniu procesu na hali produkcyjnej zwykle ma, przy systemie biurowym rzadko.

Monitoring, aktualizacje bezpieczeństwa i bieżące poprawki z zadeklarowanym czasem reakcji, rozliczane w abonamencie. Zakres i czas reakcji ustalamy przed wdrożeniem, a nie po pierwszej awarii.

Nie. System jest Wasz razem z infrastrukturą, więc utrzymanie może przejąć Wasz dział IT albo inna firma. Uważamy natomiast, że jakikolwiek monitoring jest konieczny — najgorszy wariant to dowiadywać się o awarii od klientów.

Wracamy do tego samego procesu w mniejszej skali: rozmowa, ustalenie zakresu, wycena. Systemy, które budujemy, są projektowane pod dalszy rozwój, więc rozbudowa nie powinna oznaczać przepisywania od nowa.

Gdy proces da się złożyć z gotowych narzędzi i dwóch integracji, gdy skala nie uzasadnia kosztu utrzymania własnego systemu, albo gdy problem jest organizacyjny, a nie techniczny — wtedy oprogramowanie go tylko utrwali. Krótkoterminowo to dla nas strata, długoterminowo jedyny powód, dla którego ktoś wraca.

Tak, i zaczynamy od audytu, który mówi wprost, co da się uratować, a co trzeba napisać od nowa. Nie deklarujemy przejęcia przed audytem — bez zajrzenia w kod taka deklaracja jest zgadywaniem.

To jest właściwy moment. Warsztat discovery istnieje dokładnie po to, żeby z problemu zrobić zakres — a pierwsza rozmowa, na której to ustalamy, jest bezpłatna.