Build vs Buy: Dlaczego tworzenie własnej aplikacji dla wykonawców kosztuje więcej niż się wydaje

Ta rozmowa zwykle zaczyna się tak samo. Zespół ds. transformacji cyfrowej producenta OEM przygląda się temu, jak jego wykonawcy serwisu łopat zbierają dane terenowe, i mówi: „Myślę, że sami moglibyśmy zbudować coś lepszego. Znamy nasze procesy. Mamy programistów. Jak trudne to może być?”

To rozsądny odruch. OEM widzi pofragmentowane dane napływające od wykonawców w różnych formatach, wie dokładnie, jak powinien wyglądać efekt końcowy, i dochodzi do wniosku, że stworzenie własnego narzędzia jest najprostszą drogą do rozwiązania problemu. W niektórych przypadkach ma rację. Jednak w większości przypadków rzeczywisty koszt zbudowania, wdrożenia i utrzymania aplikacji terenowej dla wykonawców jest trzy do pięciu razy wyższy niż początkowe szacunki.

Niniejszy artykuł analizuje, skąd biorą się te ukryte koszty, i proponuje strukturę decyzyjną pomagającą ocenić, kiedy budowanie własnego rozwiązania ma sens, a kiedy nie.

Atrakcyjność samodzielnego tworzenia

Zanim przyjrzymy się kosztom, warto przyznać, dlaczego samodzielne tworzenie jest kuszące. Argumenty są realne:

• Pełna kontrola nad funkcjami — narzędzie robi dokładnie to, czego Państwo chcecie, nie więcej i nie mniej
• Brak uzależnienia od dostawcy — Państwo posiadają kod, harmonogram rozwoju i dane
• Niestandardowe integracje — aplikacja łączy się bezpośrednio z Państwa wewnętrznymi systemami bez warstwy pośredniej
• Własność intelektualna — oprogramowanie staje się zastrzeżonym aktywem

To są uzasadnione korzyści. Pytanie nie brzmi, czy są realne, lecz czy warto ponosić pełne koszty ich realizacji. Na podstawie ponad dekady doświadczeń we współpracy z wykonawcami serwisu łopat odpowiedź brzmi zazwyczaj nie — i oto dlaczego.

Kategorie ukrytych kosztów

1. UX dla warunków terenowych to odmienna dyscyplina

Zbudowanie aplikacji dla użytkowników biurowych to dobrze znany problem. Zbudowanie jej dla techników pracujących na wysokości 80 metrów na linie, w rękawicach, w deszczu, na tablecie z porysowanym ochraniaczem ekranu — to zupełnie inna sprawa.

Każda interakcja musi działać jedną ręką. Przyciski muszą być wystarczająco duże, by móc je nacisnąć w rękawicach. Formularze muszą stale zapisywać stan, bo technik może zostać odwołany w połowie wpisu. Rejestrowanie zdjęć musi automatycznie oznaczać metadane, bo nikt nie będzie wpisywać opisów, wisząc przy łopacie. A wszystko to musi działać na różnych urządzeniach — od najnowszego iPada Pro po pięcioletni tablet Samsunga kupiony przez wykonawcę w dużej ilości.

Twórzenie aplikacji korporacyjnych kosztuje zwykle od 150 000 do 500 000 dolarów za pierwszą wersję². Aplikacja terenowa spełniająca powyższe wymagania plasuje się zdecydowanie w górnej części tego przedziału — i to zanim uwzględni Państwo koszty badań użytkowników, testów terenowych i iteracyjnego przeprojektowania, których wymaga użyteczny produkt.

2. Tryb offline to wielomiesięczne wyzwanie inżynierskie

Wiele lokalizacji farm wiatrowych ma ograniczony lub żaden zasięg komórkowy. Aplikacja wymagająca stałego połączenia z internetem jest w terenie bezwartościowa. Brzmi to jak proste wymaganie: „wyśtarczy zbuforować dane lokalnie i zsynchronizować po powrocie zasięgu.” W praktyce jest to jeden z najtrudniejszych problemów w inżynierii mobilnej.

Tryb offline wymaga rozwiązania:

• Rozstrzygania konfliktów — co się dzieje, gdy dwaj technicy edytują ten sam rekord w trybie offline i obaj synchronizują później dane?
• Integralności danych — jak zagwarantować, że żadne rekordy nie zostaną utracone podczas synchronizacji, nawet jeśli aplikacja zostanie zamknięta w trakcie przesyłania?
• Zarządzania pamięcią masową — zdjęcia z inspekcji są duże. Jedna kampania na turbinie może wygenerować gigabajty obrazów. Aplikacja musi inteligentnie zarządzać pamięcią lokalną, nie przepełniając urządzenia.
• Zarządzania kolejką — synchronizacja musi sprawnie obsługiwać tysiące zakolejkowanych rekordów, z logiuką ponownych prób, informacją o postępie i możliwością wznowienia przerwanego przesyłania.

Widywaliśmy aplikacje zamawiane przez OEM-ów, które wyglądały nienagannie w sali demonstracyjnej, a przy pierwszej kampanii offshore ponosiły katastrofalną klęskę, bo architektura trybu offline nie była przetestowana w realnych warunkach. Poprawne wdrożenie tego obszaru zazwyczaj wydłuża czas opracowania o trzy do sześciu miesięcy i generuje trwałą złożoność utrzymania.

3. Obsługa wielu języków to nie tylko tłumaczenie

Serwis łopat to globalny biznes. Wykonawcy i ich technicy pracują w całej Europie, obu Amerykach, Azji i Pacyfiku oraz poza nimi. Aplikacja działająca tylko w języku angielskim nie zostanie przyjęta w Danii, Niemczech, Hiszpanii ani w Polsce. A obsługa wielu języków nie jest tak prosta jak tłumaczenie ciągów znaków.

Należy zapewnić obsługę:

• Dynamicznego przełączania języków (technicy często pracują w zespołach wielojęzycznych)
• Lokalnych formatów daty, czasu i liczb
• Dostosowania układu interfejsu do języków z dłuższymi wyrazami (niemieckie złożenia rzeczownikowe rozbiłyby każdy układ zaprojektowany pod angielski)
• Bieżącego utrzymania tłumaczeń w miarę rozwoju funkcji

Każdy nowy język zwiększa nakład pracy testowej. Każda zmiana interfejsu wymaga weryfikacji we wszystkich obsługiwanych lokalizacjach. To nie jest jednorazowy koszt — to stały mnożnik każdego przyszłego cyklu wytworzenia.

4. Bieżące utrzymanie — tam właśnie są prawdziwe pieniądze

Pierwsza wersja to tańsza część. Branżowe wyniki badań porównawczych konsekwentnie pokazują, że roczne koszty utrzymania stanowią od 15 do 20 procent pierwotnego budżetu wytworzenia¹. Dla projektu o wartości 400 000 dolarów to 60 000 do 80 000 dolarów rocznie, co roku, bezterminowo.

Obejmuje to:

• Aktualizacje mobilnych systemów operacyjnych — Apple i Google wydają co roku główne wersje OS. Każda z nich może uszkodzić istniejącą funkcjonalność, co wymaga testów regresyjnych i poprawek na całej flocie urządzeń.
• atki bezpieczeństwa — aplikacja dla wykonawców obsługująca dane osobowe, lokalizacje GPS i informacje o obiektach klientów wymaga ciągłego utrzymania zabezpieczeń. Jedna nie załatana luka i mamy incydent ochrony danych.
• Fragmentacja urządzeń — wykonawcy używają mieszaniny urządzeń z iOS i Android różnych generacji. Testowanie i wspieranie tej macierzy to stałe obciążenie.
• Naprawianie błędów i obsługa zgłoszeń użytkowników — gdy aplikacja działa na żywo, prośby o funkcje i raporty błędów nigdy nie ustają. Ktoś musi je klasyfikować, priorytetyzować, poprawiać, testować i wydawać aktualizacje. To co najmniej jeden pełnoetatowy programista, często więcej.
• Testowanie — każda zmiana, bez względu na jej wielkość, wymaga testów regresyjnych na różnych urządzeniach, systemach operacyjnych i warunkach sieciowych (online, offline, chwiejne połączenie). Zautomatyzowane zestawy testów trzeba budować i utrzymywać. Ręczne testy QA są niezbędne dla scenariuszy terenowych, których nie można odwzorować w laboratorium. To stały koszt rośnący wraz z każdą dodowaną funkcją.

W ciągu pięciu lat całkowite koszty utrzymania własnej aplikacji mogą z łatwością przewyższyć pierwotny koszt jej wytworzenia — zanim zostanie dodana choćby jedna nowa funkcja.

5. Złożoność integracji kumuluje się z czasem

Aplikacja musi wymieniać dane z wieloma systemami zewnętrznymi: bazami danych szkoleń, platformami zleceń roboczych OEM, narzędziami CRM, systemami ERP i wszystkim, czego firma używa. Każda integracja to mini-projekt: mapowanie API, uwierzytelnianie, obsługa błędów, logika ponownych prób, transformacja danych.

Pierwsza integracja jest do opanowania. Bieżące koszty — nie. Zewnętrzne API zmieniają się. Platformy ERP wydają nowe wersje. Końcówki są wycofywane. Każda zmiana wymaga, by Państwa zespół zbadał sprawę, zaktualizował, przetestował i wdrożył. Jeśli Państwo mają pięć integracji, utrzymujecie pięć ruchomych celów równolegle do własnej bazy kodu.

6. Adopcja przez wykonawców to najtrudniejszy do skwantyfikowania koszt

To ryzyko przesądza o powodzeniu lub niepowodzeniu całej inwestycji. Jeśli wykonawcy nie będą używać aplikacji, nic innego nie ma znaczenia. Państwo wydali setek tysięcy funtów na narzędzie, które leży nieużywane na tabletach w desce rozdzielczej furgonetki.

Adopcja przez wykonawców kończy się niepowodzeniem, gdy:

• Aplikacja jest zbyt skomplikowana (zbudowana przez programistów, którzy nigdy nie pracowali na wysokości)
• Aplikacja jest zbyt wolna (technicy nie będą czekać na ekrany ładowania między turbinami)
• Aplikacja nie działa w trybie offline (zob. powyżej)
• Aplikacja dodaje kroki bez widocznej korzyści dla technika (postrzegana jako inwigilacja, a nie wsparcie)
• Szkolenie trwa zbyt długo (wykonawcy rotują w kampaniach i nie mogą sobie pozwolić na wielodniowe wdrożenie)

Dedykowane narzędzia rozwiązują problem adopcji, bo to ich jedyne zadanie. Dostawca, którego cały biznes zależy od tego, czy pracownicy terenowi będą korzystać z aplikacji, zainwestuje więcej w badania użyteczności, testy terenowe i iteracyjny projekt niż jakikolwiek wewnętrzny zespół IT może uzasadnić dla jednego projektu.

Co w tym obszarze naprawdę oznacza „zakup”

Gdy OEM-owie oceniają opcję „zakupu”, czasami porównują ją z generycznymi platformami usług terenowych, takimi jak ServiceMax, IFS lub modułami usług terenowych wbudowanymi w ich istniejący ERP. To porównanie jest zrozumiałe, ale mylne. Korporacyjne oprogramowanie do usług terenowych zostało zaprojektowane dla zarządzania obiektami, sektorów komunalnych i telekomunikacji. Nie powstało z myślą o procesach inspekcji łopat, klasyfikacji uszkodzeń, kontrolach bezpieczeństwa przy pracy na linach ani o sekwencjach zadań specyficznych dla OEM.

Opcja „zakupu” w serwisie łopat turbinowych w energetyce wiatrowej oznacza platformę zbudowaną specjalnie dla tej branży — taką, która już obsługuje tryb offline, wiele języków, integracje z OEM i specyficzne struktury danych wymagane przy inspekcjach i naprawach łopat. Taką, w której harmonogram rozwoju jest kierowany przez tę samą branżę, w której Państwo działają — a nie przez potrzeby sektora zarządzania obiektami czy telekomunikacyjnych usług terenowych.

Ekonomika jest prosta. Dedykowana platforma rozkrywa koszty wytworzenia na wszystkich klientów. Każdy klient korzysta z funkcji rozwijanych przez całą bazę użytkowników. Koszt na użytkownika stanowi ułamek tego, czego wymagałoby własne tworzenie, a OEM otrzymuje produkt już sprawdzony w prawdziwych kampaniach — nie prototyp, który dopiero musi się wyłowić.

Struktura decyzyjna

Samodzielne tworzenie ma sens, gdy:

• Państwa proces jest naprawdę wyjątkowy i żaden dostawca go nie obejmuje (to rzadsze, niż większość organizacji sądzi)
• Posiadają Państwo dedykowany zespół programistyczny doświadczony w aplikacjach terenowych (nie tylko webdeveloperzy)
• Są Państwo gotowi finansować bieżące utrzymanie przez co najmniej pięć lat
• Mają Państwo strategię adopcji przez wykonawców — nie tylko strategię wdrożenia

Zakup ma więcej sensu, gdy:

• Państwa główny proces jest standardowy (inspekcje, naprawy, ewidencja czasu pracy, kontrole bezpieczeństwa), ale Państwa wymagania dotyczące danych są specyficzne
• Muszą Państwo uruchomić system w ciągu miesięcy, nie lat
• Państwa wykonawcy już korzystają z platformy (natychmiastowa adopcja, brak luki szkoleniowej)
• Chcą Państwo posiadać dane, nie posiadając oprogramowania
• Czas Państwa zespołu inżynierskiego jest lepiej wykorzystany przy technologii turbin niż przy oprogramowaniu obsługującym procesy pracy wykonawców

Prawdziwe pytanie

Decyzja build vs buy to w istocie nie jest pytanie o technologię. To pytanie o to, co stanowi rdzeń Państwa biznesu, a co nim nie jest. Duże firmy OEM z globalnym zasięgiem absolutnie potrzebują własnych zdolności wytwarzania oprogramowania. Systemy ERP, platformy łańcucha dostaw i infrastruktura monitorowania turbin mają krytyczne znaczenie dla działalności i uzasadniają dedykowane zespoły. Ale aplikacja terenowa dla wykonawców to zupełnie inna sprawa. To wyspecjalizowane, branżowo specyficzne narzędzie, które musi szybko ewoluować, działać w trudnych warunkach terenowych i zdobywać adopcję wśród rozproszonej bazy wykonawców, którą Państwa organizacja nie kontroluje bezpośrednio. To nie jest wyzwanie kompetencji kluczowych. To wyzwanie ekspertyzy dziedzinowej — a ta ekspertyza wymaga lat wdrożeń terenowych, by ją zbudować.

Państwa wewnętrzne zespoły powinny budować to, co różnicuje Państwa turbiny na rynku — nie to, co zarządza wykonawcami, którzy je serwisują. Dobra wiadomość jest taka, że problem pozyskiwania ustrukturyzowanych, wiarygodnych danych od terenowych zespółów wykonawców został już rozwiązany przez ludzi, których cały biznes zależy od robienia tego dobrze. Jeśli rozważają Państwo tę decyzję, chętnie podzielimy się tym, czego dekada budowania oprogramowania terenowego nas nauczyła.

Źródła

1. Wiele źródeł branżowych, w tym Noloco, CloseLoop i Cubix, podaje roczne koszty utrzymania aplikacji na poziomie 15–20% pierwotnego budżetu wytworzenia. Zob.: Custom App Development Cost in 2025 (noloco.io), Mobile App Development Cost Breakdown (cubix.co), Mobile App Development Cost in 2025 (closeloop.com).
2. Koszty tworzenia mobilnych aplikacji korporacyjnych są szeroko szacowane na 150 000–500 000+ dolarów dla złożonych, bogatych w funkcje projektów. Źródła: App Development Costs 2026: Pricing Guide (topflightapps.com), Cost to Develop an Enterprise App in 2025 (syncrasytech.com), Mobile App Development Cost Breakdown (chopdawg.com).

← Powrót do Field Notes