Ile kosztuje aplikacja dla firmy? Zakres i sposób wyceny

Dlaczego na to pytanie nie ma jednej odpowiedzi

„Ile kosztuje aplikacja dla firmy” to pytanie, które dostajemy w pierwszym mailu częściej niż jakiekolwiek inne. Odpowiedź uczciwa brzmi: zależy od tego, co ta aplikacja ma robić, dla kogo i z czym ma się łączyć. To nie jest unik. Określenie „aplikacja do zleceń” może oznaczać prostą listę z terminami albo system z rolami, dokumentami, rozliczeniami i dostępem dla klientów. Podobna nazwa, zupełnie inny nakład pracy.

Nie publikujemy cennika aplikacji i nie podajemy widełek w pierwszej rozmowie. Każdą wycenę przygotowujemy po rozpoznaniu zakresu, bo wycena bez zakresu jest zgadywaniem, a zgadywanie kończy się aneksami. Ten poradnik ma za to pokazać wszystko, co wokół ceny da się wyjaśnić. Z czego koszt się składa. Co go podnosi, czasem niepostrzeżenie. Co go obniża bez obcinania sensu. Jak porównać oferty, które wyglądają zupełnie inaczej. Jak przygotować zapytanie, żeby odpowiedzi dało się zestawić. I co dzieje się z kosztami po wdrożeniu.

Po lekturze powinieneś umieć przeczytać ofertę wykonawcy i zobaczyć, za co płacisz, a czego w niej nie ma. Co dokładnie budujemy i od czego zaczynamy, opisujemy na stronie aplikacji dla firm. Tutaj zajmujemy się samą wyceną.

Z czego składa się koszt aplikacji

Koszt aplikacji to suma pracy nad kilkoma warstwami, które wyglądają z zewnątrz jak jedna rzecz. Klient widzi ekrany. Wykonawca widzi ekrany, logikę pod nimi, dane, połączenia, uprawnienia, testy i wdrożenie. Każda z tych warstw ma własną wagę w wycenie.

Procesy i ekrany

Liczba różnych zadań, które aplikacja ma obsłużyć, i reguły, które przy nich obowiązują. Przyjęcie zlecenia to jedno zadanie. Przyjęcie zlecenia z akceptacją kierownika powyżej pewnej wartości, z wyjątkiem dla stałych klientów i z powiadomieniem magazynu, to cztery zadania w jednym. Wyjątki kosztują więcej niż główna ścieżka, bo każdy trzeba zaprojektować, zbudować i sprawdzić osobno.

Użytkownicy i uprawnienia

Ile ról, co każda widzi i może zmienić, jak zakłada się konta i co się dzieje, gdy ktoś odchodzi. Aplikacja dla trzech osób z jednakowym dostępem jest prostsza niż aplikacja dla trzech osób, z których każda widzi co innego. Dostęp dla osób spoza firmy, na przykład klientów albo podwykonawców, dokłada osobną warstwę: rejestrację, odzyskiwanie hasła, ograniczenie widoku do własnych spraw.

Dane i migracja

Skąd dane wezmą się na starcie i jak mają wyglądać. Import z arkusza, porządkowanie duplikatów, powiązanie kontaktów ze sprawami, dokumenty i załączniki, eksport na wypadek zmiany narzędzia. Jakość obecnych danych ma tu większe znaczenie niż ich ilość. Czysty arkusz z tysiącem wierszy przenosi się łatwiej niż trzysta wierszy w pięciu wersjach tego samego pliku.

Integracje

Każde połączenie z innym systemem to osobne zadanie: sprawdzenie, co tamten system udostępnia, zaprojektowanie przepływu danych, obsługa błędów, gdy druga strona nie odpowiada, i kontrola duplikatów. Jeśli dokumentacja systemu zewnętrznego nie jest dostępna albo dostęp do interfejsu wymaga wyższego pakietu u dostawcy, koszt połączenia wymaga osobnego etapu analizy. Opisujemy to na stronie integracji systemów.

Urządzenia i warunki pracy

Czy aplikacja ma działać w przeglądarce na komputerze, czy także na telefonie w terenie. Czy monter będzie miał zasięg. Aplikacja webowa dostosowana do telefonu jest standardem. Aplikacja instalowana ze sklepu, praca bez internetu z późniejszą synchronizacją albo użycie aparatu i lokalizacji to osobne wymagania z własnym nakładem.

Uruchomienie i wprowadzenie zespołu

Testy na uzgodnionych scenariuszach, przygotowanie środowiska, przeniesienie danych, założenie kont, pokazanie zespołowi, jak pracować. Ta część bywa pomijana w porównaniach, a decyduje, czy aplikacja zacznie być używana.

Praca, której nie widać na ekranie

Rozmowy o procesie, projekt ekranów, dokumentacja, kopie zapasowe, zabezpieczenia. Oferta, która tego nie wymienia, albo to zawiera i nie mówi, albo tego nie zawiera. W obu przypadkach trzeba zapytać.

Co podnosi koszt, często niepostrzeżenie

Większość rzeczy, które podnoszą koszt aplikacji, nie wygląda groźnie w rozmowie. Pojawiają się jako „a jeszcze by się przydało” albo jako założenie, którego nikt nie wypowiedział na głos.

• Wyjątki od procesu. „Zwykle tak, ale dla tego klienta inaczej.” Każde „ale” to osobna ścieżka do zbudowania i sprawdzenia.
• Wszystkie moduły naraz. CRM, zlecenia, panel klienta i raporty w jednej pierwszej wersji oznaczają, że nic nie zostanie sprawdzone w pracy, zanim powstanie reszta.
• Integracje bez dokumentacji. Stary program branżowy, który „ma eksport”, często ma plik, który trzeba parsować, a nie interfejs. To analiza przed wyceną, a nie pozycja w cenniku.
• Generowanie dokumentów. Oferta w PDF według Waszego wzoru, protokół odbioru, faktura. Każdy szablon to projekt i obsługa wariantów.
• Praca bez internetu. Synchronizacja danych po odzyskaniu zasięgu, z obsługą konfliktów, jest jednym z najdroższych wymagań w aplikacjach terenowych.
• Powiadomienia wielokanałowe. Mail, SMS, powiadomienie w aplikacji, każde z własnymi regułami i kosztem wysyłki po stronie operatora.
• Raporty „jak w Excelu”. Dowolne przestawianie danych w aplikacji wymaga więcej pracy niż kilka przemyślanych widoków pod konkretne decyzje.
• Kilka firm w jednym systemie. Grupa spółek, oddziały z osobnymi danymi albo klienci korzystający z własnych wersji wymagają rozdzielenia danych już na poziomie projektu.
• Zmiany w trakcie budowy. Decyzja o nowej roli po zbudowaniu uprawnień oznacza przebudowę tego, co już działa.
• Funkcje AI bez ustalonego zakresu. Podsumowania, odczyt dokumentów czy szkice odpowiedzi wymagają osobnego ustalenia, co trafia do usługi zewnętrznej i kto zatwierdza wynik.

Żadna z tych rzeczy nie jest zła. Każda może być potrzebna. Problem pojawia się wtedy, gdy trafiają do zakresu bez decyzji, czy są potrzebne w pierwszej wersji. Co w aplikacji firmowej AI robi dobrze, a gdzie wymaga kontroli człowieka, opisujemy w poradniku o AI w aplikacji firmowej.

Co obniża koszt bez obcinania sensu

Obniżanie kosztu przez wykreślanie funkcji z listy jest proste i zwykle kończy się aplikacją, której brakuje czegoś ważnego. Lepiej działa kilka decyzji na początku projektu.

Jeden proces w pierwszej wersji

Zamiast zaczynać wszystkie moduły jednocześnie, wybierz jeden proces możliwy do wykonania od początku do końca. Przykład: przyjęcie zapytania, przypisanie opiekuna i zapisanie następnego kontaktu. Taka wersja ma wyraźny cel i scenariusz odbioru. Na liście kolejnych etapów mogą znaleźć się raporty, automatyczne dokumenty i panel klienta. Ustal jednak już na początku, czy są planowane, bo może to wpływać na organizację danych. Podział pracy ma wynikać z potrzeb, a nie z ukrywania pełnego kosztu. Jak wyznaczyć taki zakres, opisujemy w poradniku o pierwszej wersji aplikacji dla firmy.

Opis przypadków zamiast listy funkcji

„Chcemy moduł raportów” to lista funkcji. „Kierownik w poniedziałek rano chce wiedzieć, które zlecenia są opóźnione i kto je prowadzi” to przypadek. Z przypadku da się zbudować jeden widok. Z listy funkcji buduje się moduł, który obsłuży wszystko, czyli dużo więcej, niż ktokolwiek użyje.

Zostawienie części pracy w obecnych narzędziach

Nie wszystko musi być w aplikacji. Jeśli faktury wystawia program księgowy i to działa, aplikacja może tylko przekazać mu dane. Jeśli kalendarz zespołu działa w narzędziu, które wszyscy znają, nie buduj kalendarza. Każda rzecz, która zostaje tam, gdzie była, obniża zakres i ryzyko.

Decyzje przed budową, nie w trakcie

Role, etapy, pola na karcie, format dokumentów. Każda z tych decyzji podjęta na etapie projektu kosztuje rozmowę. Podjęta po zbudowaniu kosztuje przebudowę. Jedna osoba decyzyjna po Twojej stronie, która zbiera uwagi zespołu i przekazuje jedną listę, skraca ten etap bardziej niż cokolwiek innego.

Dane uporządkowane przed migracją

Przejrzenie arkusza i usunięcie duplikatów przed projektem jest pracą, którą ktoś z firmy może wykonać sam. Zrobione po stronie wykonawcy jest pracą, za którą płacisz. Anonimowy przykład struktury danych wysłany z zapytaniem pozwala ocenić, ile tej pracy będzie.

Standardowe elementy tam, gdzie nie ma powodu do wyjątków

Logowanie, odzyskiwanie hasła, wysyłka maili, przechowywanie plików, eksport do arkusza. Te elementy mają sprawdzone wzorce. Każde „u nas to musi wyglądać inaczej” w tych miejscach podnosi koszt bez wpływu na codzienną pracę. Oszczędzaj własne pomysły na to, co naprawdę odróżnia Wasz proces.

Jak wykonawca wycenia aplikację: co dzieje się po Twoim mailu

Wycena aplikacji nie powstaje przy biurku z kalkulatorem. Powstaje w dwóch pierwszych etapach współpracy, które opisujemy w ofercie, i jest ich wynikiem.

Na etapie poznawania sposobu pracy rozmawiamy o zadaniach, użytkownikach i obecnych narzędziach. Ustalamy, gdzie gubią się informacje, co robicie ręcznie i jaki efekt ma dać aplikacja. Nie musisz przynosić specyfikacji. Wystarczy opowiedzieć, jak dziś pracujecie, i pokazać anonimowy przykład arkusza albo obiegu zlecenia.

Na etapie projektu i ustalania zakresu pokazujemy układ ekranów i przebieg najważniejszych zadań. Ustalamy funkcje, role użytkowników, integracje oraz koszt i harmonogram pierwszej wersji. Dopiero tu pojawia się liczba, bo dopiero tu wiadomo, co ma powstać. Osobno ujmujemy utrzymanie, licencje zewnętrzne i późniejszą rozbudowę.

Założenia w wycenie

Dobra wycena wymienia założenia, na których się opiera. Że system zewnętrzny ma udokumentowany interfejs. Że dane do migracji przyjdą w ustalonym formacie. Że testy po stronie firmy wykona wskazana osoba w uzgodnionym czasie. Że aplikacja działa w przeglądarce, a nie jako program instalowany. Jeśli założenie okaże się nieprawdziwe, zakres się zmienia, a razem z nim koszt. Wycena bez założeń wygląda pewniej, ale zostawia wszystkie niewiadome na później.

Termin zależy od zakresu i od Ciebie

Termin zależy od zakresu, dostępności danych i dokumentacji obecnych narzędzi. Potwierdzamy go po analizie zakresu, nie w pierwszym mailu. Zależy też od tego, jak szybko po Twojej stronie zapadają decyzje i kiedy zespół ma czas na testy. Projekt, w którym uwagi do ekranów przychodzą po trzech tygodniach, trwa dłużej niż jego budowa.

Dwa sposoby rozliczenia

Rozliczenie za ustalony zakres daje Ci pewność kosztu w zamian za dyscyplinę w zmianach: każda zmiana zakresu jest osobno wyceniana. Rozliczenie za czas pracy daje elastyczność w zamian za mniej pewny koszt końcowy. Żaden z tych sposobów nie jest lepszy sam w sobie. Pierwszy pasuje do zamkniętej pierwszej wersji. Drugi do rozwoju po wdrożeniu, gdy zmiany są małe i częste. Oferta powinna mówić wprost, który sposób stosuje i do czego.

Ile kosztuje aplikacja dla firmy w różnych branżach: co zmienia zakres

Branża nie ma własnego cennika. Ma za to typowe elementy procesu, które zwiększają albo zmniejszają zakres. Poniżej to, co w każdej z nich najczęściej przesądza o nakładzie pracy.

Serwis i instalacje

Zakres rośnie przez pracę w terenie: karta zlecenia na telefonie, zdjęcia z montażu, podpis klienta, czasem praca bez zasięgu. Zmniejsza go zostawienie kalkulacji w arkuszu w pierwszej wersji i ograniczenie widoku montera do jednego ekranu. Najdroższym wymaganiem bywa synchronizacja bez internetu. Zanim ją zamówisz, sprawdź, jak często monter naprawdę nie ma zasięgu.

Produkcja B2B

Zakres rośnie przez kalkulację ofert zależną od parametrów, powiązanie z danymi z produkcji i historię zamówień stałych klientów. Zmniejsza go zaczęcie od panelu dla klientów ze stałym asortymentem albo od samej rejestracji zapytań. Integracja z programem produkcyjnym jest zwykle tym elementem, który wymaga osobnej analizy przed wyceną.

Handel i dystrybucja

Zakres rośnie przez cenniki zależne od klienta, stany magazynowe w czasie rzeczywistym i wiele dokumentów na jedno zamówienie. Zmniejsza go ustalenie jednego źródła prawdy dla cen i stanów, zwykle w programie handlowym, i pobieranie ich stamtąd zamiast prowadzenia w aplikacji. Jeśli celem jest panel dla odbiorców, to, co powinien zawierać, żeby był używany, opisujemy w poradniku o panelu klienta B2B.

Usługi dla firm

Biura rachunkowe, agencje, kancelarie. Zakres rośnie przez dokumenty, terminy ustawowe, komunikację z klientem i rozliczanie czasu. Zmniejsza go zostawienie obsługi merytorycznej w programach branżowych i zbudowanie tylko warstwy, której w nich brakuje: widoku dla klienta, obiegu akceptacji albo przypomnień o terminach.

Firma budowlana i remontowa

Zakres rośnie przez długi cykl jednej sprawy, zmiany zakresu w trakcie, protokoły, odbiory i wielu decydentów po stronie inwestora. Zmniejsza go ograniczenie pierwszej wersji do prowadzenia sprawy i dokumentów, bez kosztorysowania, które zostaje w dotychczasowym narzędziu.

Firmy z oddziałami

Zakres rośnie przez uprawnienia: kto widzi który oddział, kto zastępuje kogo, jakie raporty idą do centrali. Zmniejsza go uczciwa odpowiedź na pytanie, czy oddziały naprawdę pracują inaczej, czy tylko mają inne nawyki. Jeśli proces jest wspólny, a różnią się dane, aplikacja jest prostsza, niż się wydaje na początku.

Przykład z biurka: od jednego pytania do zakresu

Firma zajmująca się serwisem urządzeń chłodniczych napisała do nas jedno zdanie: „Potrzebujemy aplikacji do zleceń, ile to kosztuje”. Do maila był dołączony arkusz z zeszłego miesiąca. Zamiast odpowiadać liczbą, poprosiliśmy o rozmowę o jednym zleceniu.

Krok pierwszy: jedno zlecenie od początku do końca. Klient dzwoni, dyspozytor wpisuje zgłoszenie do arkusza i dzwoni do serwisanta. Serwisant jedzie, naprawia, wpisuje części na kartce. Kartka wraca do biura w piątek. Biuro przepisuje części do programu magazynowego i wystawia fakturę. Klient dzwoni po dwóch tygodniach z pytaniem, czy naprawa była gwarancyjna, i nikt nie wie, bo kartka jest w segregatorze.

Krok drugi: role i wyjątki. Okazało się, że są trzy role: dyspozytor, serwisant i biuro. Wyjątków było więcej, niż ktokolwiek sądził. Zgłoszenia z umów serwisowych inaczej niż jednorazowe. Naprawy gwarancyjne bez faktury. Zlecenia, które wymagają dwóch wizyt. Każdy z tych wyjątków spisaliśmy i przy każdym padło pytanie, czy musi być w pierwszej wersji.

Krok trzeci: integracje. Program magazynowy miał interfejs, ale dostęp do niego wymagał wyższego pakietu u dostawcy. Program do faktur miał tylko import z pliku. To zmieniło plan: pierwsza wersja miała przygotowywać plik do importu, a nie łączyć się bezpośrednio. Połączenie z magazynem trafiło na listę na później, do czasu decyzji firmy o pakiecie.

Krok czwarty: zakres pierwszej wersji. Zgłoszenie, przypisanie serwisanta, karta zlecenia na telefonie z listą części i zdjęciem, zamknięcie zlecenia, plik do faktury. Bez umów serwisowych, bez raportów, bez panelu dla klientów. Każda z tych rzeczy została zapisana jako kolejny etap z własnym pytaniem, które trzeba rozstrzygnąć przed jej wyceną.

Krok piąty: wycena z założeniami. Oferta wymieniała zakres, role, jedno połączenie przez plik, migrację z arkusza w ustalonej strukturze i testy z jednym serwisantem. Osobno utrzymanie i hosting. Osobno koszt dostępu do interfejsu magazynu, bo był po stronie innego dostawcy. Firma dostała liczbę, którą dało się porównać z innymi ofertami, bo miała przy sobie opis tego, co obejmuje.

Pytanie „ile to kosztuje” z pierwszego maila nie zmieniło się. Zmieniło się to, czego dotyczyło. Zamiast aplikacji do zleceń, która mogła znaczyć wszystko, dotyczyło pięciu funkcji dla trzech ról z jednym połączeniem.

Jak porównać oferty, które wyglądają zupełnie inaczej

Trzy oferty na „aplikację do zleceń” mogą różnić się kilkukrotnie i wszystkie mogą być uczciwe. Jedna wycenia prostą listę. Druga system z rolami i integracjami. Trzecia to samo co druga, ale z utrzymaniem przez rok w cenie. Porównanie samych kwot nie mówi nic. Porównanie zakresów mówi wszystko.

Wyślij do wszystkich wykonawców ten sam opis: jedno zlecenie od początku do końca, listę ról, obecne narzędzia, anonimowy przykład danych. Poproś, żeby każda oferta odpowiadała na te same pytania. Potem zestaw je w tabeli.

Jeśli oferta jest wyraźnie tańsza od pozostałych, znajdź w tej tabeli, czego w niej nie ma. Zwykle jest to migracja, testy albo utrzymanie. Jeśli jest wyraźnie droższa, znajdź, co ma więcej. Czasem to rzeczy, których nie potrzebujesz w pierwszej wersji, i wtedy warto poprosić o wariant bez nich.

Jeśli wciąż wybierasz między budową własnego narzędzia a konfiguracją gotowego programu, porównanie obu dróg opisujemy w poradniku gotowy CRM czy system dedykowany.

Jak przygotować zapytanie, żeby wycena była porównywalna

Dobre zapytanie nie musi być długie. Musi opisywać pracę, a nie wymarzony program. Wystarczy opisać obecny przebieg jednego zadania i oczekiwany efekt. Jeśli korzystacie z arkuszy, przygotujcie anonimowy przykład struktury danych. Nie przesyłajcie na tym etapie haseł, danych klientów ani dostępu do firmowych systemów. Zapytanie to opis, nie dostęp.

Pięć informacji, od których zaczyna się rozmowa

1. Najważniejsze zadanie, które aplikacja ma usprawnić, opisane jako jeden przebieg od początku do końca.
2. Obecne narzędzia: arkusze, programy, skrzynki, komunikatory, z informacją, co w nich zostaje.
3. Użytkownicy: kto, ile osób, jakie role, czy ktoś pracuje w terenie albo spoza firmy.
4. Potrzebne połączenia: z jakimi systemami, w którą stronę i czy wiesz, jak udostępniają dane.
5. Oczekiwany moment startu i to, co go wyznacza: sezon, nowy oddział, odejście osoby, która wszystko wiedziała.

Jeśli masz budżet, zaznacz, czy obejmuje tylko wdrożenie, czy również utrzymanie. Wykonawca nie dopasuje do niego ceny. Powie za to od razu, co w tym budżecie jest realne, a co trzeba przesunąć na kolejny etap. Brief na stronie wyceny pyta o te same rzeczy i przyjmuje pliki, więc możesz zacząć od briefu aplikacji.

Co dołączyć, a czego nie

• Dołącz: anonimowy arkusz z kilkoma wierszami, zrzut ekranu obecnego programu, przykład dokumentu, który aplikacja ma generować.
• Dołącz: nazwy systemów do połączenia i, jeśli masz, link do ich dokumentacji dla programistów.
• Dołącz: listę pytań, na które dziś nikt w firmie nie umie szybko odpowiedzieć, bo to z nich wynikają raporty.
• Nie dołączaj: haseł, pełnych baz klientów, umów z danymi osobowymi, dostępów do systemów.
• Nie dołączaj: listy funkcji skopiowanej z cennika gotowego programu. Opisz pracę, a funkcje wyjdą z rozmowy.

Jak przygotować zespół i dane, zanim projekt ruszy, opisujemy szerzej w poradniku o przygotowaniu firmy do wdrożenia CRM. Te same zasady dotyczą każdej aplikacji firmowej.

Budowa to jedna pozycja, utrzymanie to druga

Aplikacja po odbiorze nie przestaje kosztować. Zmienia się tylko charakter kosztu: z jednorazowego na stały. Poproś o osobne wskazanie kosztu wdrożenia, hostingu, opieki i usług zewnętrznych. Oferta, która łączy to w jedną liczbę, utrudnia porównanie i ukrywa, co dzieje się po roku.

Hosting i środowisko

Aplikacja działa na serwerze, który ktoś utrzymuje i aktualizuje. Ustal, gdzie, kto płaci i kto ma dostęp. Ustal też, czy środowisko da się przenieść do innego wykonawcy. Hosting, którego nie da się przenieść, wiąże Cię z wykonawcą mocniej niż jakikolwiek zapis w umowie.

Opieka i obsługa zgłoszeń

Nie każda firma potrzebuje tych samych zasad wsparcia. Oferta powinna wyjaśniać sposób zgłaszania problemów, zakres aktualizacji, kopie zapasowe i warunki rozwoju. W ofercie określamy dokumentację, dostępy, licencje i prawa do kodu, a także sposób zgłaszania problemów, czas reakcji oraz zakres utrzymania. Zapytaj, co dzieje się z błędem zgłoszonym w piątek po południu i kto decyduje, czy coś jest błędem, czy zmianą zakresu.

Usługi zewnętrzne i AI

Jeżeli aplikacja używa płatnego interfejsu, wysyłki SMS, map, podpisu elektronicznego albo funkcji AI, ustal sposób rozliczania użycia oraz kontrolę kosztów. Te opłaty idą do dostawców usług, nie do wykonawcy, i rosną wraz z użyciem. Przy funkcjach AI dochodzi pytanie, jakie dane trafiają do usługi zewnętrznej i czy zespół zatwierdza wynik przed użyciem. Bez limitu i podglądu zużycia pierwszy rachunek bywa zaskoczeniem.

Bezpieczeństwo i dane osobowe

Aplikacja z danymi klientów podlega tym samym przepisom co każdy inny zbiór danych osobowych, a administratorem jest Twoja firma. Tekst rozporządzenia znajdziesz na EUR-Lex. Jeśli oferta zawiera słowo „bezpieczeństwo”, zapytaj, co dokładnie oznacza. Dobrym punktem odniesienia jest lista najczęstszych ryzyk aplikacji webowych, którą publikuje OWASP. Wykonawca powinien umieć powiedzieć, które z nich adresuje i jak.

Rozwój po wdrożeniu

Każda używana aplikacja zaczyna generować pomysły. Część z nich to prawdziwe potrzeby, część to przyzwyczajenia z poprzedniego narzędzia. Ustal, jak zmiany są wyceniane i w jakich paczkach wchodzą do pracy. Zmiany wprowadzane pojedynczo kosztują najwięcej, bo każda wymaga osobnego testu i wdrożenia. Nowe moduły dodajemy na podstawie potrzeb zgłaszanych przez użytkowników, a nie na podstawie listy z początku projektu.

Lista stałych pozycji do sprawdzenia przed podpisaniem

• Hosting i środowisko. Płacisz dostawcy serwera albo wykonawcy. Zapytaj, gdzie działa aplikacja i czy da się ją przenieść.
• Opieka i zgłoszenia. Płacisz wykonawcy. Zapytaj o zakres, sposób zgłaszania, czas reakcji i o to, co jest błędem, a co zmianą.
• Kopie zapasowe. Robi je wykonawca albo dostawca serwera. Zapytaj, jak często, gdzie i kto sprawdza, że da się je odtworzyć.
• Usługi zewnętrzne. Płacisz dostawcom: SMS, mapy, podpis, AI. Zapytaj, jak liczone jest użycie i kto ma limit oraz podgląd zużycia.
• Rozwój. Płacisz wykonawcy. Zapytaj, jak wyceniane są zmiany i w jakich paczkach wchodzą do pracy.
• Czas zespołu. Płaci Twoja firma, własnym czasem. Ustal, kto jest właścicielem aplikacji, zbiera uwagi i decyduje.

Najczęstsze błędy przy zamawianiu aplikacji i czym się kończą

Każdy z tych błędów widzieliśmy więcej niż raz. Żaden nie wynika ze złej woli. Wynikają z tego, że aplikację zamawia się raz na kilka lat, a wykonawca robi to co tydzień.

• Pytanie o cenę bez opisu pracy. Odpowiedź jest zgadywaniem, a porównanie kilku zgadywań nic nie mówi.
• Specyfikacja pisana przez noc. Powstaje lista funkcji z cennika gotowego programu, która nie opisuje Waszej pracy i którą i tak trzeba przerobić w rozmowie.
• Wszystko w pierwszej wersji. Projekt trwa długo, nic nie jest sprawdzane w pracy, a gdy aplikacja startuje, połowa założeń jest nieaktualna.
• Porównanie kwot bez porównania zakresów. Najtańsza oferta wygrywa, a potem okazuje się, że nie zawiera migracji ani testów.
• Integracja założona na słowo. „Nasz program ma API” okazuje się eksportem do pliku, a połączenie wymaga osobnej analizy.
• Brak osoby decyzyjnej po stronie firmy. Uwagi przychodzą od pięciu osób w różnych mailach i są sprzeczne. Każda sprzeczność to tydzień.
• Migracja na końcu. Dane okazują się gorsze, niż ktokolwiek sądził, i start przesuwa się o czas ich porządkowania.
• Utrzymanie poza rozmową. Po odbiorze nikt nie wie, kto reaguje na błąd, kto robi kopie i kto płaci za serwer.
• Umowa bez zapisów o kodzie i danych. Przy zmianie wykonawcy firma zaczyna od zera, bo nie ma dostępu do tego, za co zapłaciła.
• Rezygnacja z testów z zespołem, bo „nie ma czasu”. Błędy wychodzą u klientów, a nie u serwisanta, który sprawdziłby kartę zlecenia w pięć minut.

Każdy z tych błędów przesuwa decyzję z początku projektu na jego środek albo koniec. Na początku decyzja kosztuje rozmowę. Na końcu kosztuje przebudowę.

Pytania do wykonawcy przed podpisaniem

Odpowiedzi na te pytania powinny znaleźć się w ofercie albo w rozmowie przed jej akceptacją. Jeśli wykonawca unika któregoś z nich, to też jest odpowiedź.

1. Co dokładnie obejmuje pierwsza wersja i czego w niej nie ma.
2. Na jakich założeniach opiera się wycena i co się stanie, gdy któreś okaże się nieprawdziwe.
3. Jak wyglądają etapy, co zobaczymy po każdym z nich i co zatwierdzamy.
4. Kto testuje, na jakich scenariuszach i kto poprawia błędy znalezione po odbiorze.
5. Jak przeniesiecie nasze dane i jak sprawdzimy, że migracja się udała.
6. Gdzie aplikacja będzie działać, kto ma dostęp do środowiska i czy da się ją przenieść.
7. Co obejmuje utrzymanie, jak zgłaszamy problemy i w jakim czasie ktoś reaguje.
8. Z jakich usług zewnętrznych aplikacja korzysta, kto je opłaca i jak liczone jest użycie.
9. Kto jest właścicielem kodu i danych po zakończeniu projektu i jaką dokumentację dostaniemy.
10. Jak zgłaszamy zmiany zakresu, kto je wycenia i kiedy wchodzą do pracy.
11. Czy inny programista będzie w stanie przejąć system na podstawie tego, co dostaniemy.
12. Ile czasu naszego zespołu projekt wymaga i w których momentach.

Ostatnie pytanie jest najczęściej pomijane, a odpowiedź na nie jest częścią kosztu. Aplikacja, przy której nikt z firmy nie ma czasu na decyzje i testy, kosztuje więcej i działa gorzej, niezależnie od ceny w ofercie.

Słownik pojęć z wycen i ofert

W ofertach na aplikacje powtarza się kilkanaście słów, które wykonawcy rozumieją precyzyjnie, a klienci różnie. Krótkie wyjaśnienia, żebyś czytał ofertę tak samo jak jej autor.

• Zakres. Lista tego, co dokładnie powstanie: funkcje, role, integracje, migracja, dokumentacja. Wycena dotyczy zakresu, więc zmiana zakresu oznacza zmianę wyceny.
• Założenia. Warunki, które wykonawca przyjął przy wycenie, na przykład dostępność dokumentacji systemu zewnętrznego. Nieprawdziwe założenie zmienia zakres.
• Pierwsza wersja, MVP. Najmniejszy zakres, który obsługuje jeden proces od początku do końca i da się sprawdzić w pracy.
• Etap, kamień milowy. Punkt w projekcie, w którym coś oglądasz, sprawdzasz i zatwierdzasz. Każdy etap kończy się decyzją po Twojej stronie.
• Rola. Zestaw uprawnień przypisany do typu użytkownika: co widzi, co może zmienić, czego nie widzi.
• Integracja, API. Połączenie z innym systemem przez jego interfejs programistyczny. Bez interfejsu integracja oznacza wymianę plików.
• Migracja. Przeniesienie danych z obecnych narzędzi do aplikacji: eksport, czyszczenie, import, sprawdzenie wyniku.
• Środowisko testowe i produkcyjne. Kopia aplikacji do sprawdzania zmian i właściwa aplikacja, na której pracuje zespół. Zmiany trafiają najpierw do pierwszej.
• Hosting. Serwer, na którym działa aplikacja. Osobny koszt, osobny dostawca albo wykonawca, osobne pytanie o przenoszalność.
• Opieka, utrzymanie. Stała usługa po wdrożeniu: reakcja na błędy, aktualizacje, kopie zapasowe, monitoring. Zakres i tryb ustalane w ofercie.
• Licencje zewnętrzne. Opłaty za usługi, z których aplikacja korzysta: SMS, mapy, podpis elektroniczny, AI. Liczone według użycia, płacone dostawcom.
• Prawa do kodu. Zapis w umowie, który decyduje, czy aplikacja jest Twoja i czy możesz ją rozwijać z kimkolwiek.
• Dokumentacja. Opis, jak aplikacja jest zbudowana, jak ją uruchomić i jak ją obsługiwać. Warunek, żeby inny programista mógł ją przejąć.
• Zmiana zakresu. Każde wymaganie, którego nie było w zatwierdzonym zakresie. Ma własną procedurę zgłaszania i wyceny.

TL;DR

• Koszt aplikacji wynika z procesów, ról, danych, integracji, urządzeń i uruchomienia, a nie z nazwy „aplikacja do zleceń”.
• Koszt podnoszą wyjątki, wszystkie moduły naraz, integracje bez dokumentacji, praca bez internetu i zmiany w trakcie budowy.
• Koszt obniża jeden proces w pierwszej wersji, opis przypadków zamiast listy funkcji, decyzje przed budową i uporządkowane dane.
• Wycena powstaje po poznaniu sposobu pracy i projekcie zakresu, z wymienionymi założeniami. Liczba po jednym mailu jest zgadywaniem.
• Porównuj zakresy, nie kwoty. Tańsza oferta zwykle nie zawiera migracji, testów albo utrzymania.
• Do zapytania dołącz opis jednego zadania, obecne narzędzia, role, połączenia i anonimowy przykład danych. Haseł nie wysyłaj.
• Budowa i utrzymanie to osobne pozycje. Usługi zewnętrzne, w tym AI, rozliczają się według użycia i wymagają limitów.

FAQ