10 rzeczy, które warto sprawdzić

Wybór firmy, która stworzy panel administracyjny lub aplikację mobilną, nie jest szczególnie trudny. Na rynku działa wiele zespołów mających doświadczenie w budowie klasycznych systemów webowych.

Sytuacja wygląda inaczej, jeśli aplikacja jest tylko jednym z elementów większego projektu badawczo-rozwojowego.

System może zbierać dane z czujników rozmieszczonych w gospodarstwach, komunikować się z maszynami, odbierać obrazy z kamer lub dronów, analizować dane w chmurze i na ich podstawie generować rekomendacje albo automatycznie sterować urządzeniami.

Wtedy wykonawca nie odpowiada już tylko za napisanie oprogramowania zgodnie z listą funkcji. Jego decyzje wpływają na sposób komunikacji urządzeń, strukturę zbieranych danych, możliwość prowadzenia eksperymentów oraz późniejsze wdrożenie rozwiązania.

Ma to szczególne znaczenie w projektach realizowanych w obszarze T3 „Rolnictwo cyfrowe” programu AGROSTRATEG. Zakres wskazany przez NCBR obejmuje między innymi platformy integrujące sensory, IoT, teledetekcję i analizę obrazu, inteligentne nawadnianie, rozwiązania wykorzystujące AI, robotykę, systemy Big Data oraz interoperacyjność danych pochodzących z różnych źródeł.

Jak więc ocenić software house, który ma odpowiadać za część IT takiego przedsięwzięcia?

1. Sprawdź, czy wykonawca rozumie cały system, a nie tylko aplikację

Pierwszą rozmowę warto wykorzystać do sprawdzenia sposobu myślenia zespołu.

Jeżeli projekt zakłada wykorzystanie sensorów, urządzeń lub maszyn, dobry wykonawca powinien zainteresować się znacznie większą liczbą elementów niż wygląd panelu użytkownika.

Powinny pojawić się pytania o to, jakie urządzenia będą źródłem danych, gdzie będą pracowały, jak często mają wykonywać pomiary, jaki jest ich sposób komunikacji, czy mają stałe zasilanie, ile urządzeń będzie działało podczas badań oraz jaka może być ich liczba po wdrożeniu rozwiązania.

Warto również omówić sytuacje nietypowe. Co stanie się po utracie internetu? Czy pomiary mogą zostać zapisane lokalnie? Czy system musi działać w czasie rzeczywistym? Czy utrata kilku kolejnych pomiarów jest dopuszczalna? Czy backend będzie wysyłał polecenia z powrotem do urządzenia?

Dzięki temu można szybko rozpoznać różnicę pomiędzy zespołem, który patrzy na projekt jako na kompletny system:

urządzenie → transmisja → backend → dane → algorytm → aplikacja

a wykonawcą, który widzi przede wszystkim zestaw ekranów do zaprogramowania.

W projektach AgriTech ta różnica może później zdecydować o tym, czy poszczególne elementy rzeczywiście uda się ze sobą połączyć.

2. Zweryfikuj doświadczenie w integracji oprogramowania z urządzeniami

Firma nie musi samodzielnie projektować elektroniki, aby dobrze realizować część software’ową projektu IoT.

Powinna jednak umieć współpracować z zespołem odpowiedzialnym za hardware.

W praktyce oznacza to wspólne ustalenie sposobu identyfikacji urządzeń, formatu przesyłanych komunikatów, obsługi błędów, wersjonowania protokołu, konfiguracji urządzeń i sposobu reagowania na utratę łączności.

Warto zapytać potencjalnego wykonawcę:

• w jaki sposób wcześniej integrował aplikacje z urządzeniami,
• jakie protokoły komunikacyjne wykorzystywał,
• jak podchodzi do identyfikacji i autoryzacji urządzeń,
• co dzieje się z danymi, gdy urządzenie przez pewien czas nie ma połączenia,
• jak rozwiązuje zmianę firmware’u lub formatu komunikatów,
• jak testuje backend, jeśli finalny hardware nie jest jeszcze gotowy.

Ostatnie pytanie jest szczególnie istotne w projektach B+R.

Hardware i software często rozwijane są równolegle. Backend nie powinien czekać kilka miesięcy na finalną wersję urządzenia. Można wcześniej określić kontrakt komunikacyjny, przygotować symulator urządzeń i zacząć testować pełny przepływ danych.

Dzięki temu problemy integracyjne pojawiają się znacznie wcześniej niż podczas końcowego pilotażu.

3. Zapytaj, kto dobierze sposób komunikacji

LoRaWAN, NB-IoT, LTE, Wi-Fi czy komunikacja przez lokalny gateway nie są zamiennymi nazwami na „Internet dla urządzeń”.

Każda z tych technologii ma inne właściwości i odpowiada na inne potrzeby.

Przykładowo LoRaWAN może być dobrym wyborem dla dużej liczby sensorów pracujących na ograniczonym obszarze i wysyłających niewielkie porcje danych. NB-IoT pozwala wykorzystać infrastrukturę operatora komórkowego i może sprawdzić się w przypadku urządzeń rozmieszczonych w wielu niezależnych lokalizacjach.

LTE będzie miało sens, gdy urządzenie musi przesyłać znacznie większą ilość informacji, natomiast w budynku posiadającym odpowiednią infrastrukturę najlepszym rozwiązaniem może okazać się zwykłe Wi-Fi albo Ethernet.

Istotne są także zużycie energii, dostępność sieci w docelowej lokalizacji, częstotliwość transmisji, dopuszczalne opóźnienia oraz koszty późniejszej eksploatacji.

Jeżeli wykonawca proponuje konkretną technologię jeszcze przed poznaniem tych parametrów, warto dopytać o uzasadnienie.

Dobór sposobu komunikacji powinien wynikać z warunków działania produktu, a nie z technologii, którą software house akurat zna najlepiej.

4. Sprawdź kompetencje backendowe i chmurowe

W systemie IoT backend jest znacznie ważniejszy niż może wynikać z pierwszego prototypu.

Podczas PoC kilka sensorów może wysyłać dane do jednego prostego serwera. Po wdrożeniu system może jednak obsługiwać setki albo tysiące urządzeń, aplikację użytkownika, moduły analityczne oraz integracje z innymi platformami.

Backend odpowiada wtedy między innymi za odbieranie komunikatów, walidację danych, identyfikację urządzeń, zarządzanie użytkownikami i uprawnieniami, konfigurację, alerty, integracje i komunikację z aplikacjami.

Warto więc zapytać wykonawcę nie tylko o język programowania czy framework.

Znacznie ważniejsze będą odpowiedzi na pytania:

Jak system będzie skalowany?

Co wydarzy się po gwałtownym wzroście liczby komunikatów?

Czy awaria jednego elementu zatrzyma odbieranie danych?

Jak rozwiązane zostaną kolejki komunikatów?

Jak monitorowana będzie infrastruktura?

Jak wykonywane będą kopie bezpieczeństwa?

Jak oddzielone zostaną środowiska badawcze, testowe i produkcyjne?

Czy będzie można niezależnie rozwijać warstwę urządzeń, backend i aplikację?

Dobrze zaprojektowana architektura nie oznacza budowania skomplikowanego systemu mikroserwisowego dla dziesięciu czujników. Powinna natomiast pozostawiać rozsądną drogę rozwoju, jeśli rozwiązanie przejdzie z etapu eksperymentalnego do rzeczywistego wdrożenia.

5. Ustal, czy wykonawca potrafi pracować z dużą ilością danych pomiarowych

System IoT bardzo szybko zaczyna generować duże zbiory danych.

100 urządzeń wykonujących pomiar raz na minutę generuje 144 tysiące pomiarów dziennie. Przy 1000 urządzeń liczba rośnie do ponad 1,4 miliona.

Do tego mogą dochodzić dane pogodowe, obrazy, logi pracy urządzeń, lokalizacja, historia konfiguracji oraz informacje pochodzące z zewnętrznych systemów.

W projekcie B+R te dane są szczególnie wartościowe, ponieważ mogą służyć nie tylko użytkownikowi końcowemu, ale także do późniejszej analizy rezultatów badań.

Warto więc ustalić, w jaki sposób wykonawca zamierza je przechowywać i przetwarzać.

Trzeba rozróżnić dane biznesowe – takie jak gospodarstwa, użytkownicy, pola czy konfiguracje – od strumienia pomiarów generowanych przez urządzenia.

Istotne są również retencja danych, agregacja, możliwość eksportu oraz zachowanie surowych pomiarów potrzebnych zespołowi badawczemu.

Jeżeli później mają na nich pracować modele AI, sposób gromadzenia danych staje się jeszcze ważniejszy.

6. Ostrożnie oceniaj deklaracje dotyczące AI

„Zrobimy to za pomocą sztucznej inteligencji” jest łatwą deklaracją. Znacznie trudniej odpowiedzieć na pytanie, jakie dane będą potrzebne i w jaki sposób zostanie zmierzona skuteczność rozwiązania.

Jeżeli AI jest istotnym elementem projektu, wykonawca powinien dopytać przede wszystkim o problem, który ma zostać rozwiązany.

Inaczej projektuje się system przewidujący zapotrzebowanie na wodę, inaczej model analizujący obraz roślin, a jeszcze inaczej rozwiązanie wykrywające nietypowe zachowanie zwierząt.

Następnym krokiem powinno być ustalenie źródeł danych i sposobu ich oznaczania.

Dobry zespół powinien potrafić porozmawiać o:

• danych treningowych,
• ich jakości i reprezentatywności,
• walidacji modelu,
• metrykach skuteczności,
• wersjonowaniu modeli,
• ponownym trenowaniu,
• sposobie wykorzystania wyniku modelu w rzeczywistym systemie.

Jeżeli celem projektu jest stworzenie algorytmu osiągającego określony rezultat badawczy, jego skuteczność powinna być mierzalna.

To dobrze wpisuje się w charakter AGROSTRATEG. W I konkursie możliwe jest finansowanie m.in. badań przemysłowych, eksperymentalnych prac rozwojowych i prac przedwdrożeniowych, przy czym projekt musi zawierać eksperymentalne prace rozwojowe.

W praktyce oznacza to, że system IT powinien wspierać nie tylko działanie finalnego rozwiązania, ale również jego testowanie i walidację.

7. Sprawdź, czy wykonawca potrafi stworzyć cały interfejs użytkownika

Warstwa użytkowa systemu może obejmować znacznie więcej niż jeden panel.

W zależności od projektu potrzebne mogą być:

panel webowy dla administratora, analityka lub osoby zarządzającej gospodarstwem,

aplikacja mobilna dla osoby pracującej w terenie,

panel badawczy pozwalający analizować surowe dane,

interfejs serwisowy umożliwiający diagnostykę urządzeń,

dashboard zarządczy pokazujący najważniejsze wyniki całego systemu.

Każda z tych osób ma inne potrzeby.

Rolnik może chcieć w kilka sekund odpowiedzieć na pytanie, czy wymagana jest jego reakcja. Badacz potrzebuje dostępu do historii pomiarów. Serwisant szuka informacji o ostatniej komunikacji konkretnego urządzenia.

Dlatego przed wyborem wykonawcy warto sprawdzić, czy potrafi nie tylko zaprogramować aplikację, ale również przejść przez proces projektowania produktu i interfejsu.

W IT Hero realizacja projektu rozpoczyna się od odkrywania potrzeb i dopasowania pomysłu klienta do możliwości technologicznych, następnie powstaje projekt UI, development oraz etap dalszego utrzymania rozwiązania.

W przypadku IoT discovery powinno objąć również architekturę urządzeń, sposób transmisji oraz przepływ danych.

8. Oceń, czy wykonawca rozumie specyfikę projektu B+R

To jedna z najważniejszych różnic pomiędzy standardowym projektem komercyjnym a projektem realizowanym w ramach AGROSTRATEG.

W zwykłym wdrożeniu wymagania są zazwyczaj stosunkowo dobrze znane. Firma wie, jakiego systemu potrzebuje, a wykonawca ma go dostarczyć.

W projekcie badawczo-rozwojowym część odpowiedzi dopiero powstanie podczas realizacji.

Może okazać się, że początkowo wybrany sensor jest zbyt mało dokładny. Zasięg komunikacji jest inny niż zakładano. Algorytm potrzebuje dodatkowych danych. Wybrany sposób analizy obrazu nie osiąga wymaganej jakości.

System powinien umożliwiać wykonywanie takich eksperymentów bez przebudowy wszystkiego za każdym razem.

Dobrym pytaniem do potencjalnego wykonawcy jest:

„Co zrobicie, jeżeli podczas realizacji badania okaże się, że musimy zastąpić jeden typ urządzenia innym?”

albo:

„Czy będziemy mogli przez kilka miesięcy równolegle zbierać dane z dwóch różnych sensorów i później je porównać?”

Odpowiedź dużo mówi o tym, czy architektura została zaprojektowana jak produkt B+R, czy jak klasyczna aplikacja biznesowa.

9. Ustal własność kodu, dokumentacji i infrastruktury

Ta część bywa pomijana przed rozpoczęciem współpracy, a staje się bardzo istotna kilka lat później.

Przed podpisaniem umowy warto jednoznacznie ustalić:

• kto posiada prawa do stworzonego kodu,
• gdzie znajduje się repozytorium,
• kto ma dostęp administracyjny do infrastruktury,
• na czyim koncie utrzymywana jest chmura,
• gdzie przechowywana jest dokumentacja,
• kto posiada dane dostępowe do usług zewnętrznych,
• czy możliwe jest przekazanie systemu innemu zespołowi,
• co wydarzy się po zakończeniu współpracy.

Szczególnie niebezpieczna jest sytuacja, w której cały projekt działa na prywatnych kontach wykonawcy, klient nie posiada dostępu do repozytorium, a wiedza dotycząca systemu istnieje wyłącznie w głowie jednego programisty.

W kilkuletnim projekcie badawczo-rozwojowym trzeba zakładać możliwość zmiany składu zespołu.

Dokumentacja powinna więc powstawać razem z rozwiązaniem.

Nie chodzi o tworzenie setek stron opisujących każdą klasę w kodzie. Znacznie bardziej potrzebne są dokumentacja architektury, opis API, protokoły komunikacji urządzeń, model danych, instrukcja uruchomienia systemu oraz opis infrastruktury.

10. Sprawdź, czy wykonawca potrafi przejść od PoC do produkcji

Wiele zespołów potrafi szybko stworzyć efektowny prototyp.

Znacznie trudniejsze jest zbudowanie systemu, który po zakończeniu badań można wdrożyć u rzeczywistych użytkowników.

Dlatego podczas rozmowy warto zapytać potencjalnego wykonawcę:

„Co zmieni się w architekturze, jeżeli z 20 urządzeń podczas pilotażu przejdziemy do 5000 urządzeń?”

Nie chodzi o oczekiwanie szczegółowej odpowiedzi przed rozpoczęciem analizy. Ważny jest sposób myślenia.

Wykonawca powinien zwrócić uwagę między innymi na skalowanie backendu, liczbę komunikatów, monitoring infrastruktury, zarządzanie urządzeniami, aktualizacje, bezpieczeństwo, logowanie zdarzeń oraz koszty chmury.

Dobry PoC może być prosty i tani.

Powinien jednak potwierdzać najważniejsze założenia technologiczne w taki sposób, aby wiedza zdobyta podczas eksperymentu była użyteczna przy kolejnych etapach.

Rozsądny proces rozwoju wygląda więc mniej więcej tak:

PoC → pilotaż → walidacja → wdrożenie → skalowanie

AGROSTRATEG jest programem nastawionym na wdrażanie rozwiązań poprawiających efektywność sektora rolnego, a jednym z jego celów szczegółowych jest zwiększenie wykorzystania nowoczesnych technologii, w tym technologii cyfrowych oraz rolnictwa precyzyjnego.

Dlatego warto patrzeć dalej niż tylko na stworzenie demonstratora potrzebnego do wykonania konkretnego zadania projektu.

Jak porównywać oferty software house’ów?

Cena jest ważna, ale porównywanie wyłącznie wartości końcowej ofert może prowadzić do błędnych wniosków.

Dwie firmy mogą otrzymać ten sam opis projektu i wycenić go zupełnie inaczej, ponieważ przyjęły inne założenia.

Jeden wykonawca uwzględni architekturę IoT, monitoring urządzeń, środowisko testowe, dokumentację i automatyczne wdrożenia.

Drugi policzy przede wszystkim aplikację webową i kilka endpointów API.

Na poziomie Excela ta druga oferta może wyglądać znacznie atrakcyjniej.

Różnica zacznie być widoczna dopiero podczas integracji urządzeń albo pierwszego większego pilotażu.

Dlatego przed porównaniem ceny warto poprosić wykonawców o przedstawienie zakresu odpowiedzialności.

Dobrym materiałem porównawczym jest prosty diagram architektury.

Poproś każdą firmę, aby pokazała, jakie elementy systemu przewiduje i za które z nich bierze odpowiedzialność:

urządzenia → komunikacja → platforma IoT → backend → baza danych → analityka → aplikacja

Bardzo szybko zobaczysz, czy porównujesz podobne oferty.

Najtańsza oferta może wygenerować najdroższy projekt

Duża część kosztów projektu IT nie wynika z pierwszego developmentu.

Powstaje później.

Jeżeli oprogramowanie jest mocno związane z konkretnym urządzeniem, każda zmiana hardware’u może wymagać przebudowy aplikacji.

Jeżeli baza danych została zaprojektowana wyłącznie pod kilka urządzeń testowych, wdrożenie na większą skalę może oznaczać migrację całej warstwy danych.

Jeżeli brak dokumentacji, zmiana zespołu może być bardzo kosztowna.

Jeżeli nie przewidziano monitoringu urządzeń, znalezienie przyczyny problemu w gospodarstwie oddalonym o kilkaset kilometrów może wymagać fizycznej wizyty serwisanta.

Dlatego przy analizie ceny warto patrzeć na cały cykl życia systemu, a nie tylko koszt pierwszej wersji.

Czerwone flagi podczas rozmowy z wykonawcą

Kilka zachowań powinno skłonić do dokładniejszej weryfikacji oferty.

Pierwszym jest przedstawienie wyceny bardzo szybko, mimo że projekt obejmuje hardware, IoT, dane i AI, a wykonawca praktycznie nie zadał pytań technicznych.

Drugim jest rozpoczynanie rozmowy od wyboru frameworka, zanim ustalony został przepływ danych.

Trzecim może być proponowanie jednej technologii komunikacyjnej do każdego zastosowania.

Niepokojące jest również założenie, że pierwsza wersja sensora, protokołu i modelu AI pozostanie niezmieniona przez cały okres realizacji projektu B+R.

Warto uważać także na systemy, w których dostęp do infrastruktury, repozytorium albo dokumentacji posiada wyłącznie wykonawca.

Osobną kategorią są obietnice dotyczące sztucznej inteligencji. Jeżeli firma potrafi obiecać wysoką skuteczność modelu przed zobaczeniem danych, warto poprosić o wyjaśnienie, na jakiej podstawie została oszacowana.

Jak przygotować zapytanie do wykonawcy?

Nie trzeba posiadać gotowej specyfikacji technicznej.

Na pierwszym etapie znacznie bardziej przydatny będzie opis tego, co ma wydarzyć się w świecie rzeczywistym.

Przykładowo:

„Chcemy mierzyć wilgotność gleby w 20 punktach na polu. Pomiary będą wykonywane co 15 minut. Podczas pilotażu system będzie działał w trzech gospodarstwach, a po wdrożeniu chcemy obsługiwać kilkaset gospodarstw. Dane będą połączone z prognozą pogody i wykorzystane do rekomendowania nawadniania. Rolnik ma otrzymywać rekomendacje w aplikacji mobilnej.”

Taki opis pozwala rozpocząć projektowanie.

Warto uzupełnić go o informacje dotyczące dostępnych już urządzeń, integracji, planowanej skali, użytkowników, oczekiwanych rezultatów badań i elementów, które mają dopiero zostać zweryfikowane.

Na tej podstawie wykonawca powinien pomóc przełożyć koncepcję na architekturę techniczną.

Wybór podwykonawcy w AGROSTRATEG – pamiętaj również o formalnościach

W przypadku prac finansowanych w ramach projektu trzeba rozdzielić dwa zagadnienia: techniczne dopasowanie wykonawcy oraz prawidłowy sposób jego wyboru i rozliczenia.

NCBR wskazuje w FAQ konkursu AGROSTRATEG I, że podwykonawca nie musiał być wybrany już na etapie składania wniosku. Koszt można było oszacować i ująć we wniosku, przy czym jego wartość powinna odpowiadać realiom rynkowym. NCBR wskazuje również, że wybór podwykonawcy powinien zostać odpowiednio udokumentowany, m.in. poprzez zapytanie ofertowe, otrzymane oferty, kryteria oceny, protokół wyboru i umowę.

Dokumentacja konkursowa przewiduje przy tym kategorię kosztów związaną z podwykonawstwem. Aktualizacja przewodnika kwalifikowalności kosztów z 13 maja 2026 r. dotyczyła nawet sposobu uwzględniania kosztów podwykonawstwa przy naliczaniu kosztów pośrednich.

Przed rozpoczęciem postępowania warto więc każdorazowo sprawdzić aktualną dokumentację konkursu, umowę o dofinansowanie oraz zasady kwalifikowalności obowiązujące konkretny projekt.

Technicznie najlepszy wykonawca nadal musi zostać zaangażowany zgodnie z zasadami dotyczącymi realizacji projektu.

Checklista przed podpisaniem umowy

Przed podjęciem decyzji warto odpowiedzieć sobie na dziesięć pytań:

1. Czy wykonawca rozumie cały przepływ danych od urządzenia do użytkownika?
2. Czy ma doświadczenie w integracji software’u z urządzeniami?
3. Czy potrafi dobrać i zaprojektować sposób komunikacji IoT?
4. Czy posiada kompetencje backendowe i chmurowe?
5. Czy potrafi przechowywać i analizować dane telemetryczne?
6. Czy realistycznie podchodzi do AI i potrafi zaplanować jego walidację?
7. Czy może stworzyć potrzebne aplikacje webowe i mobilne?
8. Czy rozumie iteracyjny charakter prac badawczo-rozwojowych?
9. Czy projekt będzie odpowiednio udokumentowany, a prawa i dostęp do infrastruktury jasno określone?
10. Czy rozwiązanie będzie można rozwinąć od PoC do rzeczywistego wdrożenia?

Jeżeli odpowiedzi dotyczą wyłącznie samej aplikacji, a nikt nie chce rozmawiać o urządzeniach, danych, komunikacji i późniejszym wdrożeniu, prawdopodobnie warto poszukać innego partnera.

Software house w projekcie AGROSTRATEG powinien być częścią zespołu technicznego

W projektach rolnictwa cyfrowego granica pomiędzy hardware’em i software’em bardzo szybko się zaciera.

Sposób działania sensora wpływa na komunikację. Komunikacja wpływa na strukturę backendu. Rodzaj zbieranych danych wpływa na możliwość stworzenia modelu AI. Wynik algorytmu musi później trafić do aplikacji lub urządzenia wykonawczego.

Dlatego największą wartość daje wykonawca, który potrafi rozmawiać z zespołem hardware’owym, naukowcami i osobami odpowiedzialnymi za biznesową stronę rozwiązania.

Jego zadaniem nie powinno być jedynie napisanie kodu zgodnie z otrzymaną listą ekranów.

Powinien pomóc przełożyć założenia badawcze na system, który można zbudować, przetestować i później wdrożyć.

Szukasz wykonawcy IT do projektu AGROSTRATEG?

IT Hero specjalizuje się w tworzeniu aplikacji webowych i mobilnych oraz wdrażaniu rozwiązań IoT, między innymi z wykorzystaniem LoRaWAN i NB-IoT. Firma działa od 2021 roku i ma siedzibę w Toruniu.

Możemy przejąć całą warstwę software’ową projektu albo odpowiadać za jej wybrany fragment – przykładowo backend IoT, komunikację urządzeń, platformę webową lub aplikację mobilną.

Współpracę możemy rozpocząć jeszcze przed przygotowaniem szczegółowej specyfikacji.

Jeżeli masz już opis projektu, wniosek, schemat działania urządzenia albo wymagania dotyczące części IT, możemy wspólnie przejść przez planowany przepływ danych i określić, z jakich komponentów powinien składać się system.

Na tej podstawie łatwiej będzie ocenić zakres prac, ryzyka techniczne i przygotować realizację kolejnych etapów – od pierwszego prototypu po wdrożenie.

Realizujesz projekt AGROSTRATEG i szukasz wykonawcy części IT lub IoT? Porozmawiajmy o Twoim projekcie.

Umów rozmowę