Przekrój cenowy stworzenia aplikacji jest bardzo duży od kilkunastu tysięcy nawet do kilku milionów złotych.
Cena aplikacji zależy od:
2 główne modele rozliczeń z wykonawcą aplikacji:
Witaj w 12 lekcji kursu Mobile Academy. Dzisiaj odpowiedź na odwieczne pytanie, ile kosztuje aplikacja.
Bardzo dobrze na to pytanie odpowiedział Marcin Zaręba w książce "Marketing dla menagerów", mianowicie odpowiedź na pytanie, ile kosztuje aplikacja, to mniej więcej ta sama odpowiedź jak na pytanie, ile kosztuje samochód. To zależy.
Tak naprawdę przekrój aplikacji jest bardzo duży. Od aplikacji, które są stworzone tylko po to, aby jedną spełnić funkcję, na przykład jakiejś służyć konferencji, do aplikacji, które są utrzymywane przez lata i służą, jako core business dla danej firmy. Tak, więc przekrój cen aplikacji może wynosić od kilkunastu tysięcy do kilku milionów złotych. W zależności od tego, jaki czas aplikacja będzie tworzona i w jaki sposób będzie utrzymywana. Tak, więc zastanówmy się nad kilkoma tematami, które wpływają na to, ile tak naprawdę ta aplikacja kosztuje.
Mamy cały zestaw różnych czynników, które mogą wpływać, zwykle poprzez zwiększenie ceny takiej aplikacji.
Po pierwsze, rzeczy oczywiste, czyli z jednej strony liczba platform, na które aplikacja musi być wykonana, zwłaszcza, jeżeli tworzymy z wykorzystaniem technologii natywnych i tak naprawdę musimy dla każdej platformy stworzyć osobny projekt.
Ponadto liczba ekranów, z których aplikacja się składa, czyli ile tak naprawdę pracy po stronie zarówno grafików, jak i programistów musi zostać wykonane, żeby zaprojektować i stworzyć poszczególne ekrany aplikacji.
Następnie to, czy aplikacja obsługuje API, czyli komunikuje się z zewnętrznymi systemami i dodatkowo na ile złożona jest ta komunikacja, jak dużo danych jest pobierane, czy te dane są synchronizowane, czy nie są synchronizowane i tak dalej i tak dalej.
To są zagadnienia, które wpływają na to, jak technicznie złożona jest ta aplikacja. Ponadto dodatkowo, jeżeli mamy w naszej aplikacji konieczność obsługiwania użytkowników, logowania, przetrzymywania ich danych, to dodatkowo komplikuje taką aplikację.
Potem mamy jeszcze złożoność UI i o ile tutaj mamy z jednej strony liczbę tych ekranów, czyli to, ile trzeba rzeczy zaprojektować i stworzyć, o tyle złożoność UI, czyli to, w jaki sposób te ekrany są niestandardowe i wymagają od programistów dodatkowej pracy po to, żeby stworzyć bardzo ładnie wyglądające czy to animacje, czy to elementy graficzne, to dodatkowo wpływa na cenę takiej aplikacji.
Następnie mamy nietypowe technologie, tu chodzi głównie o elementy takie, jak komunikacja z użyciem na przykład bluetooth’a lub innych protokołów, wykorzystywanie jakichś technologii, jakichś złożonych algorytmów, rozpoznawanie obrazu, rozpoznawanie dźwięku i tak dalej i tak dalej. Im bardziej nietypowe rzecz chcemy zrobić, tym aplikacja będzie droższa.
I ostatni element, który wpływa na cenę, to to, ile chcemy pieniędzy przeznaczyć na publikację oraz marketing takiej aplikacji, czyli jak duży przygotowaliśmy budżet na to, żeby aplikacja już po pojawieniu się w sklepie była dostępna dla użytkowników i zdobywała popularność. Tak, więc mamy dużo czynników i każdy z tych czynników wpływa na tą cenę.
Teraz, jeśli postanawiamy rozliczać taką aplikację, to mamy dwa modele współpracy. Takie podstawowe dwa modele, które są wykorzystywane po to, aby rozliczać się z wykonawcą. Te modele, to model Fixed Price, którym określamy cenę za cały produkt do przygotowania, oraz model Time & Material, w którym płacimy za czas poświęcony na wykonywanie tej aplikacji.
Oczywiście, można tutaj wykonywać różne wariacje tych obu tematów, czyli można na przykład płacić za fragmenty aplikacji lub płacić jakieś fragmenty, a potem przejść na system, w którym płacimy już za godzinę, jeżeli na przykład aplikacja powstała i tylko utrzymujemy ją.
Tak, więc oba te systemy różnią się dosyć znacznie i oba maja swoje wady i zalety. W przypadku Fixed Price podstawową zaletą jest to, że z góry wiemy, ile pieniędzy wyłożymy na to, żeby aplikacja powstała. Jednak jest jedna podstawowa wada tego rozwiązania. Mianowicie, jeżeli komuś powiemy, że mamy tyle i tyle pieniędzy za daną aplikację, to musimy być pewni, że w tych pieniądzach da się wykonać to, co jest założone i teraz każda niepewność przy przygotowywaniu takiej aplikacji oznacza, że musimy dołożyć margines, który jest przeznaczony na to, gdyby się okazało, że ta aplikacja będzie trudniejsza niż zakładaliśmy, albo będzie miała jakieś problemy. Dlatego w przypadku Fixed Price zwykle cena jest większa niż zakładamy, że faktycznie będzie potrzebne. To są tak zwane marginesy.
Z drugiej strony, w przypadku Time & Material płacimy tylko za to, co faktycznie zostało wykonane. Oczywiście w tym przypadku nie mamy tak naprawdę pewności, ile do końca wyniesie ta ostateczna kwota za naszą aplikację. Istnieją tutaj rozwiązania, które pozwalają to ograniczyć. Przykładowo, można korzystając z metodyk zwinnych, dostarczać aplikację w pewnych iteracjach i wtedy płacimy tylko za poszczególne iteracje. Jeżeli w którymś momencie stwierdzimy, że kończy nam się budżet lub, przykładowo, widzimy, że do tej pory wyłożone pieniądze nie dały odpowiedniego efektu, możemy w dowolnym momencie przerwać współpracę i ewentualnie poszukać innego wykonawcy.
Tak, więc obie wersje mają swoje wady i zalety, i warto dopasować to do tego, czy ta aplikacja ma być rozwijana czy nie ma być rozwijana, czy ma określony dokładnie zakres, czy nie wiemy jeszcze, jakie funkcjonalności będziemy chcieli w tej aplikacji dodać.
### W kolejnej lekcji
W kolejnej lekcji opowiem o tym, jak właśnie korzystać ze Scrum, czyli takiej metodyki zwinnej, która pozwala tworzyć aplikację kawałek po kawałku, dzięki czemu możemy lepiej określić, ile kosztują poszczególne elementy i płacić tylko z nie. Do zobaczenia w kolejnej lekcji i jak zwykle przypominam, że można się ze mną skontaktować pod adresem sylwester@byoutline.com lub korzystając z innych kanałów komunikacji. Do zobaczenia.
Prezentacja z lekcji nr 12
Prezentacja w formacie PDF.
How much to make an app (ENG)
Generator “wyceny” projektu, który obrazuje jakie czynniki wpływają na cenę aplikacji.
Cost to Build a Mobile App: A Survey (ENG)
Wyniki ankiety przeprowadzonej wśród firm tworzących aplikacje.
Figuring the costs of custom mobile business app development (ENG)
Zbiór linków do stron o wycenie aplikacji.