Jak przygotować się do wyceny aplikacji lub produktu IoT?

Dobra wycena aplikacji nie zaczyna się od pytania „ile to kosztuje?”, tylko od materiałów, które pozwalają wycenić ten sam zakres. Jeśli napiszesz tylko „proszę o wycenę i timeline”, oferty łatwo rozjadą się trzykrotnie — bo każdy domyśli się innego MVP.

Poniżej checklist, jak przygotować się do wyceny aplikacji mobilnej, webowej, SaaS albo produktu IoT — oraz kiedy lepsze są warsztaty produktowe.

Warsztaty produktowe przed wyceną

Zakres MVP, user stories, ryzyka i brief do oferty — zanim zaczniesz płacić za development.

Poznaj warsztaty produktowe

Co musi wiedzieć wykonawca, żeby wycenić uczciwie?

1. Problem i użytkownik (nie lista ekranów)

• Jaki problem rozwiązujesz?
• Dla kogo (jedna persona na start)?
• Jak wygląda sukces MVP (metryka)?

Bez tego wycena staje się „wyceną listy życzeń”.

2. Zakres MVP vs później

Podziel funkcje na:

• Must — bez tego nie ma walidacji,
• Should — warto, jeśli budżet pozwoli,
• Later — świadomie po feedbacku.

To najcenniejsza część briefu. Więcej o tym: co to jest MVP.

3. Forma produktu

Napisz wprost (albo daj się doradzić):

• web / PWA / mobile / desktop,
• czy jest urządzenie (BLE, IoT, wearable),
• czy AI jest częścią hipotezy, czy tylko „fajnie mieć”.

4. Integracje i ograniczenia

Najbardziej windują koszt:

• płatności (Stripe, Przelewy24, BLIK),
• ERP/CRM,
• OpenAI / własne modele,
• BLE / firmware / sprzęt od zewnętrznego producenta,
• RODO, medtech, wymagania UE,
• twardy deadline przy ograniczonym budżecie.

5. Materiały, które przyspieszają wycenę

• Figma / prototyp UX,
• przykłady konkurencji,
• istniejący kod / API,
• dokumentacja urządzenia (przy hardware),
• limity budżetowe i preferowany model współpracy.

Checklist briefu (do skopiowania)

• Opis problemu i persony (5–10 zdań)
• User stories MVP (nawet w punktach)
• Lista „później / poza zakresem”
• Platformy (iOS/Android/web) + języki
• Integracje i konta zewnętrzne
• Design: jest / nie ma / do zrobienia
• Budżet orientacyjny lub twardy limit
• Deadline i powód deadline’u
• Czy potrzebne NDA
• Preferowany model: stała cena / Time & Material / nie wiem

Im więcej punktów masz domkniętych, tym węższe widełki w ofercie.

Kiedy brief wystarczy, a kiedy warsztaty?

Sytuacja	Co robić
Masz Figmę + backlog	Konsultacja → wycena
Masz pomysł + kilka zdań	Warsztaty albo dłuższy discovery
Wyceny różnią się mocno	Ujednolicić zakres warsztatami
Hardware + app + niepewność	Warsztaty + ewentualnie PoC
Twardy budżet	Warsztaty pod warianty zakresu A/B/C

Warsztaty nie są „opóźnieniem projektu” — to zwykle najtańszy sposób, by nie kupić złego zakresu.

NDA i formalne zapytanie ofertowe

Jeśli potrzebujesz formalnej wyceny albo wzoru oferty:

1. NDA (jeśli wymaga tego IP albo tajemnica handlowa),
2. pytania doprecyzowujące zakres,
3. oferta z założeniami i listą wyłączeń,
4. opcjonalnie warsztaty, jeśli zapytanie jest zbyt ogólne.

Bez listy założeń „tania oferta” często oznacza niewycenione ryzyka.

Jak czytać ofertę software house’u?

Sprawdź:

• czy wycenione są te same user stories,
• co jest poza zakresem (utrzymanie, store’y, CE, treści),
• ile iteracji UX jest w cenie,
• jak wygląda zmiana zakresu w trakcie,
• kto realnie pracuje w zespole.

Porównanie samych kwot końcowych bez tego jest bezużyteczne.

Orientacyjne rzędy wielkości

• warsztaty: kilka–kilkanaście tys. zł,
• proste MVP web: ~40–120 tys. zł,
• MVP mobile: ~80–200 tys. zł,
• MVP SaaS: ~100–250 tys. zł.

Szczegóły: ile kosztuje MVP aplikacji i cennik MVP.

Podsumowanie

Do wyceny aplikacji przygotuj problem, personę, zakres MVP, integracje i materiały. Jeśli nie potrafisz tego spisać w jeden wieczór — nie zaczynaj od developmentu; zacznij od discovery. Dobry brief chroni budżet lepiej niż „szybki start bez zakresu”.

Budowa MVP — od briefu do walidacji

Pomożemy domknąć zakres, wycenić MVP i zbudować pierwszą wersję produktu do testów z użytkownikami.

Zobacz usługi budowy MVP