Gotowy produkt czy oprogramowanie dedykowane: kiedy które wybrać

Kupują Państwo CRM, bo kierownik sprzedaży nie radzi sobie już z notatkami, a po trzech miesiącach obok systemu stoi Excel z trzema cennikami i teczka z fakturami, które ktoś przepisuje do księgowości. Produkt nie jest gorszy od tego, za co został sprzedany, bo zna klienta, transakcję i następny telefon, ale nie zna Państwa procesu, bo ten proces nie był tym, co producent budował dla setek firm, i ta szczelina jest tematem całego artykułu: czy kupują Państwo narzędzie do swojego procesu, czy proces do swojego narzędzia, a nie dziurę w liście funkcji, którą da się zasypać jednym dostosowaniem. Jeśli dziurą jest połączenie między systemami, które już robią swoją pracę, to nie jest argument za budową: najpierw spinamy to, co już jest.

Gotowy produkt czy oprogramowanie dedykowane: kiedy które wybrać, nie jest pytaniem o to, który przycisk wygląda nowocześniej, i nie jest też pytaniem o to, czy są Państwo „dostatecznie duzi, żeby budować sami”. Nasza odpowiedź jest tą samą, którą zapisaliśmy na stronie usługi: jeśli Państwa proces mieści się w gotowym narzędziu, proszę wziąć gotowe narzędzie, będzie taniej, a system dedykowany ma sens wtedy, gdy proces jest częścią Państwa przewagi konkurencyjnej albo gdy gotowe rozwiązania wymagają zbyt wielu kompromisów, i to zdanie nie jest chwytem sprzedażowym, żeby potem i tak sprzedać budowę, tylko testem, którym tracimy wiersze, w których trzeba by napisać kolejny CRM, i zatrzymujemy te, w których proces jest częścią przewagi albo gotowe narzędzia wymagają zbyt wielu kompromisów.

Ten artykuł nie jest porównaniem platform sklepu internetowego, bo to już napisaliśmy gdzie indziej, i nie jest też cennikiem oprogramowania dedykowanego, bo takiego artykułu nie mamy i mieć nie będziemy, bo cen nie wymyślamy z głowy, i nie jest też obietnicą, że własny system zawsze wygrywa. Sprzedajemy zarówno wdrożenie gotowego produktu, jak i budowę od zera, a uczciwy tekst zaczyna się od tego, że czasem najdroższą usługą, jaką możemy Państwu sprzedać, jest ta, której Państwu nie potrzeba, dlatego dalej jest granica, po której ten wybór da się zrobić, zanim ktoś sprzeda Państwu sprint.

Gotowy produkt czy oprogramowanie dedykowane: kiedy które wybrać

Proszę wziąć gotowy produkt, jeśli proces się w nim mieści, i zamówić oprogramowanie, jeśli proces jest Państwa przewagą konkurencyjną albo gotowe narzędzia wymagają zbyt wielu kompromisów: to jest cała odpowiedź, a reszta tego artykułu to to, jak to zdanie sprawdzić wobec konkretnej pracy, nie wobec prezentacji. Porównanie, które zaczyna się od tabeli funkcji, kończy się, zanim się zaczęło, bo tabela pokazuje to, co producent nazwał, nie to, kto po roku rozstrzygnie o Państwa następnej zmianie.

Skutki z niewłaściwej strony nie są symetryczne, bo gotowe narzędzie, w które wcisnęli Państwo swój proces siłą, staje się abonamentem plus Excelem plus człowiekiem, który trzyma jedno i drugie razem, a ten człowiek po roku jest droższy niż jakakolwiek licencja, natomiast system dedykowany dla procesu, który już żyje w księgowości, programie pocztowym i standardowym CRM, jest budową, którą będą Państwo utrzymywać sami, choć na rynku utrzymuje ją już ktoś inny. W pierwszym przypadku kupili Państwo produkt, a potem napisali drugi system obok niego, w drugim napisali Państwo system tam, gdzie wystarczyła licencja, i oba błędy kosztują dłużej, niż wygląda to w ofercie.

Nazywamy tę granicę, bo w jednym tygodniu widzieliśmy oba końce: firmę, która chciała „własnego HubSpota”, choć potrzebowała HubSpota, i firmę, która przez trzy lata wyginała gotowy ERP wokół swojej tabeli cen i wreszcie przyszła po tę samą tabelę jak po nowy projekt, nie dlatego, że „ERP nie potrafi”, tylko dlatego, że kompromisów było już więcej niż konfiguracji. Żaden z tych stanów nie jest wynikiem złej woli, bo oba zaczynają się od zdania „potrzebujemy systemu”, które jeszcze nie jest testem, a test zaczyna się dopiero wtedy, gdy zapiszą Państwo proces na jednej stronie bez nazwy narzędzia i dopiero potem szukają, które narzędzie tę stronę już robi.

Zanim kupią Państwo cokolwiek, proszę zapisać, co system ma robić pierwszego dnia, czego nie wolno mu zapomnieć w drugim roku, i kto może ten drugi rok zmieniać bez cudzego wydania, bo jeśli odpowiedzi mieszczą się w produkcie, który da się skonfigurować, proszę wziąć produkt. Jeśli pytanie to katalog, ceny, zamówienie i dostawa w sklepie internetowym, to jest test sklepu, i my go tu nie przepisujemy; jeśli odpowiedzią jest proces, którego konkurent nie może kupić jako gotowego narzędzia, dopiero wtedy ma sens rozmowa o sprincie. Ten artykuł sprzedaje dalej tę kolejność, nie narzędzie.

Czym jest gotowy produkt, a czym oprogramowanie dedykowane

Gotowy produkt to oprogramowanie, które ktoś już napisał dla wielu i które nabywają Państwo albo subskrybują, żeby z niego korzystać bez istotnej przebudowy. W planowaniu wydatków publicznych, którego dotyczą rekomendacje Urzędu Zamówień Publicznych w sprawie zamówień na systemy informatyczne, COTS bierzemy tu jako gotowe komercyjne oprogramowanie bez istotnego dostosowania, a SaaS jako aplikację dostępną w internecie jako usługę w abonamencie. To są definicje do planowania, nie obowiązek prywatnej firmy, i bierzemy je tu jako słowa, które już zostały nazwane, nie jako ustawę, która nakłada na Państwa uzgodnienie z administracją.

Oprogramowanie dedykowane jest systemem pisanym pod Państwa proces, a w tych samych wytycznych oprogramowanie specjalistyczne to oprogramowanie opracowane indywidualnie na potrzeby konkretnej instytucji albo branży. Nazywamy to także systemem dedykowanym, na stronie usługi systemem niestandardowym, a w tytule oprogramowaniem dedykowanym, i to nie są trzy produkty, tylko jedna praca: kod, który zaczyna się od Państwa procesu, nie od założenia producenta o tym, czym jest klient, zamówienie albo faktura, dlatego różnica nie brzmi „lepsze” przeciw „gorsze”, tylko kto potem może to założenie zmienić.

Gotowy produkt nie jest nieudaną budową dedykowaną, a budowa dedykowana nie jest lepszym CRM, bo WooCommerce jest gotowym produktem e-commerce, Moodle jest gotową platformą szkoleniową, WordPress jest gotową platformą treści, i wszystkie trzy sprzedajemy jako wdrożenie, nie jako ukrytą budowę pod inną nazwą. Laravel nie jest produktem w tym znaczeniu: to framework, na którym piszemy systemy dedykowane od wersji 4.0 z 2013 roku, i nie daje katalogu, koszyka ani CRM, dopóki ktoś ich nie napisze, więc pomylić framework z produktem znaczy wyobrazić sobie, że „na Laravelu” już jest odpowiedzią, choć to tylko sposób, w jaki odpowiedź się pisze.

Trzecią rzeczą, którą w tym miejscu zwykle się miesza, jest abonament przeciw własności, bo SaaS znaczy, że płacą Państwo za korzystanie, a dane trzyma dostawca, licencja wieczysta znaczy, że zapłacili Państwo za prawo do korzystania z wersji, a aktualizacje często są osobnym wierszem, natomiast kod dedykowany, który przekazujemy, znaczy, że kod źródłowy, dokumentacja i konfiguracja infrastruktury są Państwa. W żadnym z tych wierszy nie ma automatycznego zwycięstwa, jest tylko jasność, co kupują Państwo, bo w przeciwnym razie po roku spierają się Państwo o to, czy „system jest nasz”, gdy w rzeczywistości jest abonament, który można wypowiedzieć.

Test, którym dokonujemy tego wyboru

Test nie brzmi „czy podoba nam się ten ekran”, tylko to, czy proces, którego nie wolno Państwu oddać konkurentowi, mieści się w narzędziu, które konkurent może kupić w tym samym sklepie: jeśli się mieści, narzędzie jest właściwą odpowiedzią, bo będzie taniej i utrzyma je ktoś, którego jedyną pracą jest to narzędzie, a jeśli się nie mieści, bo tabela cen, zatwierdzenie zamówienia albo warunki dostawy są tym, czym się Państwo różnią, wtedy gotowy produkt staje się kompromisem, a kompromis znaczy tu, że proces zaczyna żyć w Excelu obok systemu.

Druga strona tego samego testu jest zbyt często zapominana, bo potrzeby częściej są wspólne niż unikalne, i programu pocztowego się nie buduje, księgowości, która już robi to, czego wymaga ustawa, się nie buduje, i standardowego lejka sprzedażowego, w którym transakcja jest transakcją, też się nie buduje. Instytucje, które wydają swoje pieniądze według spisanych kryteriów, nazwały tę samą formę inaczej: najpierw pytają, czy na rynku już jest rzecz, i budują wtedy, gdy dostępne produkty nie pokrywają rdzenia albo gdy rzeczą trzeba zarządzać samemu, i to nie jest obowiązek prywatnej firmy, i my go takim nie czynimy, ale to jest ta sama forma: mówimy nie budowie, którą da się kupić.

Trzecim błędem jest przebudowa produktu, aż przestaje być produktem, bo konfiguracja zostaje we wspieranych granicach (pola, role, przepływy, które producent przewidział), natomiast dostosowanie, które przepisuje rdzeń, żeby proces „wreszcie pasował”, wydaje właśnie tę przewagę, dla której produkt kupiono: aktualizacje, dokumentację, to, że błąd znajduje ktoś inny. Widzieliśmy to we wdrożeniach Moodle’a, gdzie najpierw sprawdzamy, czy wtyczka już istnieje, i dopiero wtedy piszemy własną, oraz na witrynach WordPressa, gdzie gotowego motywu nie stawiamy, bo wnosi dziesiątki funkcji, których Państwu nie potrzeba i które stają się zagrożeniem dla bezpieczeństwa, dlatego produkt z cudzym rdzeniem nie jest systemem dedykowanym, tylko produktem, któremu wyjęli Państwo rdzeń producenta.

Ten test robimy na warsztacie discovery, nie na slajdzie oferty, bo na slajdzie zawsze wygrywa budowa, która wygląda na troskę o Państwa, a na warsztacie wygrywa proces, który da się nazwać. Jeśli po dwóch dniach okazuje się, że proces mieści się w gotowym narzędziu, mówimy to, także wtedy, gdy znaczy to, że transakcja tego tygodnia nie jest naszym systemem niestandardowym, bo artykuł, który zawsze kończy się na „zbudujemy Państwu własne”, nie jest testem, tylko ofertą, która chowa się za pytaniem.

Kiedy gotowy produkt jest właściwą odpowiedzią

Gotowy produkt jest właściwą odpowiedzią tam, gdzie proces już został nazwany w branży i to nie Państwo tę nazwę wymyślili, bo poczta, księgowość, która wystawia fakturę tak, jak wymaga ustawa, standardowy CRM sprzedażowy, platforma szkoleniowa, która rejestruje kurs i wykonanie, oraz mały sklep z jedną ceną i jednym magazynem są miejscami, w których budowa nie daje niczego, za co warto byłoby płacić różnicę między licencją a sprintem. Tych wierszy nie sprzedajemy jako „rozwiązania tymczasowego, aż będą Państwo gotowi na prawdziwy system”, bo to są prawdziwe systemy dla tych procesów.

Te produkty także sprzedajemy, i to nie jest ukryta obietnica, że po roku przyjdzie budowa: WordPress zostaje platformą treści z motywem, który piszemy my, nie z gotowym motywem ze sklepu; małemu sklepowi ze standardowymi procesami sami mówimy WooCommerce; Moodle zostaje platformą szkoleniową, którą konfigurujemy, migrujemy i dostosowujemy wizualnie, nie wymyślamy od nowa. Ceny tych wierszy stoją na stronach usług i w jednym miejscu niżej w tym artykule, gdzie trzeba pokazać, że dolna granica oprogramowania dedykowanego nie jest automatycznie najdroższym wierszem, a tutaj wystarczy powiedzieć, że produkt zostaje produktem.

Skutkiem, jeśli w tym miejscu jednak zamówią Państwo budowę, nie jest „lepsza kontrola”, tylko utrzymanie, którego nie dzielą już Państwo z tysiącami innych, bo łatkę bezpieczeństwa programu pocztowego ktoś wydaje wszystkim, a łatkę własnego programu pocztowego wydają Państwo, i to brzmi jak wolność, dopóki nie ma drugiej nocy, w której trzeba poprawić to, co producent już poprawił w swoim produkcie. Tę wolność sprzedajemy tam, gdzie proces na nią zasługuje, nie tam, gdzie wystarczy licencja, bo w przeciwnym razie sprzedajemy Państwu pracę, którą po roku znienawidzą Państwo jako drogi duplikat.

Dlatego najuczciwszą rzeczą, jaką możemy powiedzieć przed jakąkolwiek niestandardową wyceną, jest lista produktów, które zamiast tego byśmy Państwu polecili: jeśli proces to szkolenia, proszę zacząć od Moodle’a, jeśli proces to treść, proszę zacząć od WordPressa, jeśli proces to mały sklep, proszę zacząć od WooCommerce’a, i jeśli proces to faktury oraz ustawowa ewidencja, proszę zacząć od księgowości, którą Państwo już mają, i dopiero wtedy zapytać, czy coś z tego ma stać się własnym systemem. Ta lista nie jest umową partnerską, to test, którego używamy przeciwko sobie.

Kiedy oprogramowanie dedykowane jest uzasadnione

Oprogramowanie dedykowane jest uzasadnione wtedy, gdy proces jest częścią Państwa przewagi konkurencyjnej albo gdy gotowe rozwiązania wymagają zbyt wielu kompromisów, i proces może pozostać podporządkowany towarowi, a mimo to być częścią tego testu, bo testem jest liczba kompromisów, nie to, czy sprzedają Państwo oprogramowanie. Jeśli gotowy produkt zaczyna wymagać, żeby stali się Państwo przeciętnym klientem, a przeciętny klient nie jest Państwa przewagą, budowa jest wreszcie testem, który proces wytrzymał, nie chęcią własnego ekranu.

Integracja nie jest tu argumentem sama w sobie, bo produkty też mają interfejsy, i my je podłączamy, a argument zaczyna się dopiero wtedy, gdy interfejs nie wystarcza i proces wymaga, żeby prawda o stanie, cenie albo statusie żyła w jednym miejscu, które Państwo kontrolują. Portal map Sadales tīkls, który zbudowaliśmy na Laravelu i Leaflecie, pokazuje wyłączenia, wolną moc i opłatę przyłączeniową, i to nie jest „mapa plus wtyczka”, bo opłata i moc są procesem operatora, nie polem produktu mapowego; w portalu Elektrum sesja SSO dołącza się do każdego żądania, zanim konfigurator Vue zacznie rysować, i to nie jest „motyw energetyczny na WordPressie”, bo sesja jest częścią usługi, nie dekoracją.

Kolor, logo i układ menu nie są tym testem, bo da się je zrobić w produkcie, i my je w produkcie robimy: motyw Moodle’a z Państwa paletą, motyw WordPressa bez zbędnego, sklep WooCommerce, który wygląda jak Państwa firma. Jeśli jedyne, czego nie da się zrobić w gotowym narzędziu, to „żeby wyglądało jak my”, nie doszli Państwo do oprogramowania dedykowanego, tylko do motywu, a pomieszać te dwie rzeczy znaczy płacić za budowę tam, gdzie wystarczy projekt, i potem dziwić się, dlaczego utrzymanie jest drogie dla systemu, którego jedyną różnicą jest kolor.

Nie mówimy też, że każda branża automatycznie wymaga własnej platformy, bo nazwa branży nie jest testem, a testem jest, czy proces tej branży w Państwa firmie jest tym samym, co producent już włożył w pakiet, czy jest Państwa sposobem, w jaki branża pracuje, i tego sposobu nie wolno kupić obok. Jeśli można kupić, proszę kupić; jeśli nie można, wtedy mowa o dedykowanym systemie biznesowym, i dopiero wtedy warto mówić o warsztacie discovery, nie o motywie.

Trzecia droga: produkt z naszym kodem na wierzchu

Między gotowym produktem a budową od zera jest trzecia droga, którą także sprzedajemy i którą porównania najczęściej pomijają: produkt zostaje produktem, a na wierzchu piszemy to, czego produkt nie robi, i to nie jest „odrobinę oprogramowania dedykowanego”, tylko decyzja, żeby zostawić rdzeń tam, gdzie utrzymuje go producent, i pisać tylko tę warstwę, która jest Państwa. Portal usług Sadales tīkls stoi na October CMS, a kalkulatory, kalendarze i zgłoszenie awarii są pracą na produkcie, nie nowym silnikiem treści; we wdrożeniu Moodle’a najpierw sprawdzamy, czy wtyczka do oceniania albo raportów już istnieje, i dopiero wtedy piszemy własną, bo w przeciwnym razie sprzedajemy Państwu duplikat.

Jeśli pytanie to katalog, ceny, zamówienie i dostawa, to jest test sklepu, i jest już napisany w artykule o wyborze między WooCommerce’em a Laravelem, dlatego tutaj go nie przepisujemy i nie zamieniamy w domyślny system niestandardowy. Jeśli pytanie dotyczy CRM, ERP, panelu wewnętrznego albo procesu branżowego, proszę zostać tutaj, bo sklep jest jednym przypadkiem tego samego testu, nie treścią całego wyboru.

Po stronie WordPressa trzecia droga wygląda jak odmowa, bo gotowych motywów nie stawiamy, wnoszą funkcje, które stają się zagrożeniem dla bezpieczeństwa, i budujemy czysty motyw tylko z tym, co potrzebne, a to nadal jest produkt: redaktor pisze w WordPressie, nie w wymyślonym przez nas edytorze, i aktualizacje przychodzą z WordPressa, nie z naszego jednego wydania. Różnica między tym a systemem dedykowanym jest taka, że proces treści mieści się w produkcie, ale proces motywu nie mieści się w motywie z ThemeForest, i pomieszać je znaczy albo wstawić cudzy motyw i potem dziwić się wtyczkom, albo budować własny CMS dla treści, dla których CMS już istnieje.

Ta granica jest też miejscem, w którym mówimy nie „niewielkiej przebudowie”, która po trzecim miesiącu jest rdzeniem, bo jeśli dostosowań robi się więcej niż konfiguracji, jeśli każda aktualizacja wymaga najpierw naszego kodu, jeśli pole producenta nie jest już prawdą, nie są już Państwo na trzeciej drodze. Są Państwo na budowie, która chowa się za nazwą produktu, i wtedy uczciwiej jest nazwać budowę i liczyć ją jako budowę, bo w przeciwnym razie płacą Państwo za produkt, którego już nie da się aktualizować, i za system, którego jeszcze nie da się przejąć.

Pieniądze i czas są formą, nie cennikiem

System dedykowany u nas zaczyna się od 8000 €, a pełny cykl zwykle zajmuje od 12 do 32 tygodni, i to jest „od”, nie rachunek, a 12 tygodni to nie te same pierwsze trzy miesiące, w których obiecujemy używalne MVP: dolna granica to najkrótsza budowa, MVP to krok, po którym z systemu już się korzysta, a 32 tygodnie to górna granica większej pracy, która mieści się też w tym, co w ogólnym FAQ nazywamy sześcioma do ośmiu miesiącami przy dużym systemie dedykowanym. Strona Laravela zaczyna się od tej samej dolnej granicy 8000 € i 6–24 tygodni, i to nie jest tańsze oprogramowanie dedykowane: to jest strona dla kogoś, kto już wie, że praca jest na Laravelu, nie test, czy praca w ogóle jest budową.

Te liczby nie mogą stać się zdaniem „oprogramowanie dedykowane jest najdroższym wyborem”, bo wdrożenie Moodle’a zaczyna się od 15 000 €, wersja Pro sklepu kosztuje 9500 €, i obie są powyżej dolnej granicy oprogramowania dedykowanego, bo jedno jest wdrożeniem dużego produktu, drugie sklepem z magazynem i cenami B2B. Porównywać dolną granicę 8000 € z dolną granicą Moodle’a jako „budowę przeciw produktowi” to zła arytmetyka, bo porównywać można tylko dwie drogi tego samego procesu, i nawet wtedy obie strony są dolnymi granicami, nie sumami; przy większych niestandardowych pracach rozliczamy się za czas i materiały z tygodniowym limitem, bo stała cena znaczy tam zwykle narzut na ryzyko albo spór o zakres, a stawka godzinowa wynosi 50 €.

Abonament przeciw budowie też nie jest wzorem, w którym po N latach jedna strona automatycznie wygrywa, a planowanie wydatków publicznych nazywa to, co widzimy także w umowach prywatnych: opłata SaaS może rosnąć z liczbą użytkowników albo indeksacją, integracje zostają Państwa kosztem, a zmiana dostawcy wymaga planu wyjścia, bo dane stoją u niego. To nie jest procent budowy, który cytowalibyśmy tutaj, bo przypis za takimi liczbami prowadzi do blogów dostawców, i takich liczb nie zapisujemy, ale forma zostaje: abonament jest wierszem co roku, budowa jest dolną granicą plus utrzymaniem, i żadna z nich nie jest bez wiersza.

Akt w sprawie danych, stosowany w Unii od 12 września 2025 roku, pomaga wyeksportować dane możliwe do wyeksportowania z usługi chmurowej i zakazuje dostawcy stawiać przeszkody przy zmianie, ale równoważności funkcjonalnej wymaga od usługi infrastruktury, nie od CRM, który po prostu „przenoszą Państwo”, a rozporządzenie 2023/2854 nie obiecuje, że proces przeniesie się razem z plikiem. Artykuł 20 RODO przenosi dane osobowe, które podmiot dostarczył, nie aplikację, nie Państwa konfigurację, nie reguły biznesowe, dlatego jeśli chcą Państwo systemu, który można przenieść do innego programisty, to jest kod źródłowy, który przekazujemy, nie eksport z cudzego panelu, i to jest też to miejsce, w którym kończy się ta część, bo następne zdanie byłoby już cennikiem, którego na to pytanie nie mamy.

Czego nie mówimy, gdy mówimy o oprogramowaniu dedykowanym

Nie mówimy, że własny system zawsze jest mądrzejszy, że gotowy produkt jest dla tych, którzy „jeszcze nie urośli”, albo że po trzech latach budowa na pewno się zwróciła, bo taka krzywa bez Państwa procesu jest wymysłem. Artykuł, który po uczciwym początku i tak dochodzi do tego, że trzeba kupić budowę, zaszedł za daleko, i widzieliśmy to dostatecznie często, żeby tutaj stanąć, bo uczciwość jest ograniczeniem, a krótki test jest celem.

Nie mówimy też, że Laravel jest odpowiedzią na pytanie o gotowy produkt, bo Laravel jest sposobem, w jaki piszemy, gdy test już dał budowę, a sprzedać framework człowiekowi, któremu potrzebny jest Moodle, znaczy sprzedać młotek człowiekowi, któremu potrzebna jest półka. Nasza strona Laravela zaczyna się od 8000 € i mówi o API, kolejkach i testach, ale ten artykuł mówi o tym, czy w ogóle potrzebują Państwo tej strony, a pomieszać je znaczy, że wybierają Państwo narzędzie, zanim wybrali Państwo pracę.

Nie mówimy również, że warsztat discovery jest ukrytym sposobem, żeby wciągnąć Państwa w budowę, bo wynikiem warsztatu jest plan, który zostaje użyteczny także wtedy, gdy zdecydują się Państwo z nas nie skorzystać, i czasem plan mówi: proszę wziąć produkt, który już Państwo nazwali, a my go wdrożymy, albo wdroży ktoś inny. Jeśli to zdanie brzmi Państwu jak stracona transakcja, to dlatego, że jest straconą transakcją, i wolimy stracić budowę, w której trzeba by napisać kolejny CRM, niż pozyskać klienta, który po roku pyta, dlaczego utrzymuje system, który można było abonować.

W zamówieniu publicznym ten test nie działa tak samo jak u prywatnej firmy i nie przenosi się na nią, bo w planowaniu państwowym najpierw pyta się, czy na rynku już jest gotowe rozwiązanie, i to należy do zamówienia, nie do tego zdania, natomiast po stronie prywatnej należą Państwa proces i nasz cennik. Obie strony mogą dojść do tej samej odpowiedzi, i nie dochodzą do niej dlatego, że jedna byłaby ustawą drugiej.

Jak podejmujemy tę decyzję u nas

Praca zaczyna się od 2–3-dniowego warsztatu discovery, na którym razem z Państwa zespołem omawiamy procesy, role użytkowników, ryzyka i zakres MVP, i to nie jest poranek slajdów, tylko praca, po której możemy powiedzieć, czy proces mieści się w gotowym narzędziu, czy wymaga trzeciej drogi, czy jest budową. Jeśli odpowiedzią jest produkt, warsztat zwrócił się tym zdaniem; jeśli odpowiedzią jest budowa, następnym krokiem nie jest kod.

Zanim powstanie kod produkcyjny, w dwóch do trzech tygodniach przygotowujemy klikalny prototyp, bo w nim zmiana zdania jest tańsza niż w gotowym systemie, a prototyp nie jest „żeby było co pokazać zarządowi”, tylko miejscem, w którym widzą Państwo, że tabela cen, którą Państwo wczoraj nazwali, jest w rzeczywistości inną tabelą, i w którym to odkrycie kosztuje dni, nie miesiące. Dopiero potem zaczyna się realizacja: w pierwszych trzech miesiącach budujemy MVP, którego da się naprawdę używać, a dalej rozszerzamy iteracyjnie, w dwutygodniowych sprintach z demonstracją po każdym.

Na końcu otrzymują Państwo kod źródłowy, dokumentację i konfigurację infrastruktury i mogą Państwo to przenieść do innego programisty, i to nie jest obietnica, że przeniesienie będzie przyjemne, tylko obietnica, że nie są Państwo przywiązani do naszego konta. W większych projektach zostajemy przy rozliczeniu za czas i materiały z tygodniowym limitem, a granicę MVP mimo to ustalamy na sztywno, bo w przeciwnym razie „agile” staje się słowem, za którym znika zakres, i jeśli po warsztacie idą Państwo inną drogą, plan zostaje Państwu, jak zapisaliśmy na stronie usługi, i ten artykuł tego nie zmienia.

Zanim napiszą Państwo do nas, proszę zapisać proces na jednej stronie bez nazwy narzędzia i zaznaczyć, których wierszy nie wolno Państwu oddać cudzemu wydaniu: jeśli strona jest pusta albo jest na niej tylko „żeby był własny system”, potrzebują Państwo produktu, i tak też powiemy, ale jeśli na stronie jest proces, którego konkurent nie może kupić jako gotowego narzędzia, wtedy warto mówić o budowie. Proszę do nas napisać, jeśli chcą Państwo, żebyśmy ten opis przeczytali razem z Państwem i powiedzieli, która strona wyboru do Państwa należy, także wtedy, gdy odpowiedzią jest wziąć produkt, który już Państwo nazwali.