blog · dotacje · 6 sierpnia 2026 · 10 min czytania

Aplikacja z dotacji: jak opisać zakres i wycenę, żeby przeszły przez wniosek

Wygląda to zwykle tak. Ktoś przysyła link do naboru, termin składania wniosków wypada za sześć tygodni, a w firmie jest jedno zdanie: „chcemy aplikację do obsługi zleceń”. Z tego zdania nie da się zrobić wniosku, bo oceniający nie dostaje pomysłu, tylko dokument. Ocenia to, co w nim napisano: zakres, kosztorys, harmonogram i wskaźniki.

Druga rzecz, która potrafi zaskoczyć: wniosek trzeba wypełnić kwotami, zanim ktokolwiek zacznie budować. Firma prosi więc dostawcę o wycenę i dostaje albo widełki „od 80 do 250 tys. zł”, albo jedną okrągłą kwotę bez rozbicia. Jedno i drugie jest w dokumencie słabe: pierwsze nie nadaje się do kosztorysu, drugie wygląda jak liczba wzięta z sufitu, bo nią jest.

To nie jest poradnik wypełniania formularza, bo formularze i warunki zmieniają się z każdym naborem, a wiążący jest wyłącznie regulamin, który podpisujesz. Jest o czymś węższym: jak przygotować zakres, kosztorys i harmonogram budowy oprogramowania, żeby obroniły się przed oceniającym i dały się rozliczyć bez tłumaczenia, na co poszły pieniądze.

Co w tej części wniosku jest naprawdę oceniane

Nabory na cyfryzację małych i średnich firm różnią się progiem dofinansowania, wkładem własnym i katalogiem kosztów, a liczby zmieniają się między turami, więc sprawdzaj je wyłącznie w aktualnej dokumentacji swojego naboru. Za to część opisowa dotycząca oprogramowania wraca w prawie każdym wniosku w tym samym kształcie i to ona zwykle decyduje o punktach:

  • Problem i stan obecny – co dziś nie działa, mierzone w czymś policzalnym. Nie „brak cyfryzacji”, tylko „dwie osoby przepisują zamówienia z maili do arkusza”.
  • Zakres rzeczowy – co powstanie, w kawałkach, które da się odebrać. Tu większość wniosków jest za ogólna.
  • Kosztorys – ile kosztuje każdy kawałek i skąd ta kwota się bierze. Oceniający pyta o zasadność, nie o to, czy jest tanio.
  • Harmonogram – kiedy co powstaje, z zapasem na Twoje decyzje, nie tylko na pracę dostawcy.
  • Wskaźniki i trwałość – co zmierzysz po zakończeniu i co zostaje w firmie, gdy dofinansowanie się skończy.

Te pięć elementów musi się zgadzać między sobą. Jeżeli w zakresie jest siedem rzeczy, a w kosztorysie trzy pozycje, dokument się rozjeżdża i wraca do uzupełnienia. Dlatego pisz je równolegle, z jednej listy funkcji.

Zakres: od „aplikacji do zarządzania firmą” do listy, którą da się ocenić

Największy błąd zakresu to opis produktu zamiast opisu pracy. „System klasy ERP wspierający procesy sprzedażowe” nic nie znaczy: nie wiadomo, ile w tym roboty ani jak sprawdzić, że powstało. Zamień to na listę rzeczy, które ktoś kliknie i odbierze.

Metoda jest banalna: opisz jeden dzień pracy osoby, która będzie z tego korzystać, i wypisz każdy moment, w którym dziś sięga po telefon, arkusz albo zeszyt. Każdy z nich to kandydat na ekran. Potem dopisz, kto jeszcze zagląda do systemu – to role i uprawnienia. Na końcu wypisz, z czym system musi się dogadać: program księgowy, bank, płatności.

  • Ekrany zamiast modułów. „Przyjęcie zlecenia, lista zleceń z filtrami, karta zlecenia ze statusem i historią” jest odbieralne. „Moduł zleceń” nie jest.
  • Role wprost. Kto co widzi i czego nie może zrobić. Bywa punktowane osobno, bo dotyka bezpieczeństwa danych.
  • Połączenia nazwane po imieniu. Nie „integracje z systemami zewnętrznymi”, tylko „wystawienie faktury w programie księgowym po zamknięciu zlecenia”.
  • Dane na wejściu. Skąd bierzecie to, co dziś siedzi w arkuszach: import, ręczne przepisanie, obie drogi. To realna praca, a prawie nigdy nie ma jej w opisach.
  • Granica zakresu. Zdanie „czego projekt nie obejmuje” ratuje rozliczenie, bo ucina dyskusję o rzeczach, których nikt nie obiecywał.

Taka lista ma zaletę niezależną od dotacji: jest gotowym materiałem do wyceny. Na jej podstawie podajemy przedział godzin, a Ty widzisz, która pozycja jest droga i czy musi być w pierwszym etapie.

Zanim napiszesz zakres, przejdź proces z osobą, która go wykonuje, i notuj czasowniki: przyjmuje, sprawdza, dzwoni, przepisuje, drukuje, wysyła. Zakres napisany z czasowników zespołu broni się sam. Zakres z rzeczowników z ulotki dostawcy – nie.

Kosztorys: godziny razy stawka zamiast kwoty z sufitu

Kosztorys ma odpowiadać na jedno pytanie: dlaczego akurat tyle. Najłatwiej odpowiedzieć, gdy kwota jest iloczynem, a nie liczbą. U nas stawka jest jedna i publiczna: 600 zł netto za godzinę pracy inżyniera, za wszystko – rozmowę o zakresie, projekt ekranów, kod, testy, uruchomienie i dokumentację. Kosztorys robi się więc sam.

Trzy typowe punkty odniesienia, które w dokumencie wyglądają jak konkret, bo nim są:

  • Klikalna makieta – 10 h: 6 000 zł netto. Ekrany, które przeklikasz jak aplikację, na danych przykładowych. Świetny załącznik do wniosku i najtańszy sposób, żeby pokazać oceniającemu, o czym mowa.
  • Pierwsza działająca wersja – 30 h: 18 000 zł netto. Prawdziwe dane, osobne loginy dla zespołu, historia zmian, uruchomienie. Od tego dnia firma pracuje w systemie, a nie w arkuszu.
  • Pełniejszy wariant – 60 h: 36 000 zł netto. Raporty, panel do zarządzania, dokumenty, płatności albo połączenie z tym, czego firma już używa.

Przy większych budżetach dochodzi bonus godzin, naliczany automatycznie: za 30 opłaconych godzin masz na saldzie 31,75 h, za 60 godzin – 67,25 h, a za 100 godzin (60 000 zł netto) – 120 h. We wniosku wpisuj to, co realnie płacisz, czyli godziny opłacone razy stawka. Bonus zostaje Twoim zapasem na poprawki, bo kwota w dokumencie ma zgadzać się co do złotówki z fakturą.

Zakres etapu II: działająca wersja systemu obsługi zleceń (30 h pracy inżynierskiej x 600 zł netto/h = 18 000 zł netto). Powstają: przyjęcie zlecenia, lista zleceń z filtrami, karta zlecenia ze statusem i historią zmian, konta dla 6 pracowników z podziałem na role, import 2 400 rekordów z arkuszy, uruchomienie środowiska testowego i produkcyjnego. Odbiór: protokół i raport godzin z opisem zadań.

Wzór pozycji zakresu i kosztorysu do wniosku. Robotę robią tu trzy rzeczy: iloczyn zamiast kwoty, lista odbieralnych elementów i nazwany sposób odbioru.

Dołóż koszty, które i tak poniesiesz u kogokolwiek: hosting 0–200 zł miesięcznie, domena ok. 60 zł rocznie, prowizje operatora płatności i licencje zewnętrznych usług, jeśli Twój pomysł ich wymaga. W części naborów są kwalifikowalne, w części nie – sprawdź katalog kosztów, a jeśli nie są, wpisz je do budżetu firmy.

Osobno sprawdź podatek. W wielu naborach VAT jest niekwalifikowalny dla firm, które go odliczają, a to przesuwa rachunek o 23%: przy wersji za 18 000 zł netto mówimy o 4 140 zł z własnych środków, niezależnie od poziomu dofinansowania.

Sprawdź, od kiedy wydatek jest kwalifikowalny: zwykle po złożeniu wniosku albo po podpisaniu umowy. Makieta zamówiona wcześniej, żeby mieć co pokazać, do kosztorysu najczęściej nie wejdzie. Warto ją zrobić, ale z własnych środków i jako załącznik – tego akurat nie da się naprawić po fakcie.

Harmonogram: etapy, które przetrwają zderzenie z terminem

Harmonogram we wniosku jest w miesiącach, a projekt informatyczny mierzy się w godzinach pracy. Te miary trzeba pogodzić uczciwie: „system powstanie w 30 godzin” w dokumencie rozliczanym kwartałami wygląda niepoważnie, a wpisanie 12 miesięcy dla samego zapasu ustawia najgorszy rytm, czyli całą pracę w ostatnim kwartale.

Nasz realny kalendarz wygląda tak: kontakt od inżyniera prowadzącego do 24 godzin od płatności, 30 minut rozmowy o zakresie, w ciągu 1–3 dni projekt ekranów do wglądu, praca w blokach z krótkimi akceptacjami co 2–8 godzin, na koniec środowisko testowe i po Twoim OK wersja produkcyjna. Makieta bywa gotowa w kilka dni roboczych, działająca wersja to zwykle 2–3 tyg., pełniejszy wariant 5–8 tyg.

  • Etap wpisany w harmonogram = etap, który da się odebrać. Makieta, wersja działająca, rozszerzenie. Każdy z własną kwotą i własnym protokołem.
  • Bufor po Twojej stronie, nie po naszej. Urlopy, zamknięcie miesiąca, sezon. To one przesuwają projekty, nie kod.
  • Rezerwa na zmianę zakresu. Przy pracy godzinowej zmiana nie wymaga aneksu, wymaga godzin. Zaplanuj ich kilka, zamiast udawać, że nic się nie zmieni.
  • Kolejność od najbardziej bolącego. Jeśli nabór wymusi cięcie budżetu, tniesz ostatni etap, a nie ten, dla którego projekt powstał.
  • Zapas na dokumenty. Odbiór, protokół i faktura też muszą zmieścić się w terminie rozliczenia, a to zwykle 2–3 tyg. po ostatniej godzinie pracy.

Trwałość, prawa i wskaźniki: co zostaje po zakończeniu projektu

Trwałość rezultatu to rubryka, którą wypełnia się szybko, a sprawdza po latach: firma ma nadal korzystać z tego, co powstało za publiczne pieniądze. Dlatego własność jest tu ważniejsza niż w zwykłym projekcie.

  • Pełne autorskie prawa majątkowe do kodu przechodzą na Ciebie po każdym opłaconym etapie. Nie licencja, nie prawo do korzystania: własność.
  • Repozytorium z historią zmian, dokumentacja uruchomienia i dostępy są u Ciebie, więc projekt może prowadzić dalej inny zespół albo Twój pracownik.
  • Brak abonamentu, bez którego aplikacja przestaje działać. Rezultat nie zależy od tego, czy będziecie dalej z nami współpracować.
  • Faktura VAT od aveneo – uncrn jest marką software house aveneo, działającego od 2008 roku, więc na fakturze, w umowie i we wniosku widnieje ten sam podmiot. Niespójność danych wykonawcy to klasyczne pytanie przy rozliczeniu.
  • Poufność od pierwszej wiadomości, wprost z regulaminu, przed jakimkolwiek podpisem. Potrzebujesz własnego wzoru: przygotujemy swój w 24 h albo sprawdzimy Twój w 1–3 dni.

Do rozliczenia potrzebny jest jeszcze dowód, że praca została wykonana. U nas powstaje sam, bo każda godzina trafia do logu w panelu, z datą, opisem i linkiem do efektu:

wt · −3 h · import 2 400 zleceń ze starych arkuszy + walidacja duplikatów – 37 rekordów odrzuconych do ręcznej weryfikacji, lista w panelu

Przykładowy wpis z logu pracy. Data, liczba godzin, opis i efekt do kliknięcia – dokładnie to, o co pyta się przy rozliczeniu wydatku.

Jeśli projekt dotyka danych osobowych, dopisz zdanie o pracy na etapie testów. U nas pokazy i wersje testowe jadą na danych syntetycznych, czyli zmyślonych, a nie na prawdziwych rekordach Twoich klientów. To zamyka temat, który przy dotacjach wraca jako pytanie o zgodność z RODO.

Na koniec wskaźniki. „Zwiększenie efektywności” nie jest wskaźnikiem, „skrócenie czasu obsługi zlecenia z 25 do 10 minut, mierzone w systemie” jest, bo aplikacja sama zapisuje te dane. Wybieraj takie, które nowy system liczy automatycznie, i dopisz je do zakresu jako ekran raportu. Wtedy sprawozdanie robi się samo, zamiast być osobnym projektem raz na pół roku.

Jeśli dotacji nie będzie: plan B, który nie wyrzuca pracy do kosza

Powiedzmy to wprost: nabór można przegrać, a projekt oparty wyłącznie na dofinansowaniu potrafi wtedy stanąć na dwa lata. Dlatego przygotowanie wniosku warto ułożyć tak, żeby miało wartość niezależnie od wyniku. Zakres rozpisany na ekrany i role jest gotowym materiałem do wyceny u dowolnego wykonawcy, a kosztorys w godzinach mówi, ile ten pomysł kosztuje naprawdę.

Najtańsza wersja planu B: zrób makietę za 6 000 zł netto, pokaż ją zespołowi i dwóm klientom, a potem decyduj, czy budujesz od razu, czy czekasz na kolejny nabór. Jeśli to nie tędy droga, kosztowało Cię 6 000 zł zamiast 60 000 zł i pół roku. Jeśli tędy – masz załącznik do wniosku. Niewykorzystane godziny zostają na saldzie bezterminowo.

Jak zacząć: opisz, co dziś nie działa i ile Was to kosztuje w godzinach pracy, i pokaż arkusze, w których żyje proces. Z tego robimy listę ekranów, przedział godzin i rozbicie na etapy, czyli dokładnie to, czego potrzebuje wniosek. Estymatę dostajesz na piśmie, zanim cokolwiek ruszy. Czego nie zrobimy: nie napiszemy za Ciebie wniosku ani nie ocenimy szans w naborze – od tego są doradcy śledzący regulaminy. Nasza część to zakres, godziny i harmonogram, które obronią się w dokumencie.

Wolisz liczby na własnym projekcie?

Rozłóż swój projekt na etapy i godziny (15 min)

wszystkie wpisy