Aplikacje natywne
Osobny kod na iOS i Android ma sens, gdy aplikacja żyje z aparatu, lokalizacji, Bluetooth albo powiadomień w tle. Kosztuje więcej, za to nie walczy z systemem. Interfejs budujemy w SwiftUI i Jetpack Compose.
Co robimy: aplikacje na telefon, od makiety po kolejne aktualizacje
Zakres jest węższy, niż mógłby być, i to celowo, bo w jednej dziedzinie da się być naprawdę dobrym, a w dziesięciu już tylko poprawnym. Robimy aplikacje mobilne i wszystko, czego one potrzebują, żeby działać. Poniżej sześć rzeczy, o które pytacie najczęściej, i kilka, których świadomie nie robimy.
Jeden kod na dwie platformy
Przy aplikacjach opartych na listach, formularzach i koncie klienta wspólna baza kodu skraca budowę i późniejsze poprawki, bo każdą zmianę wprowadza się raz. Większości firm to wystarcza. Gdyby później któryś moduł potrzebował kodu natywnego, da się go dopisać bez przepisywania reszty.
Pierwsza wersja do sprawdzenia pomysłu
Najpierw klikalna makieta, potem wersja z jedną ścieżką doprowadzoną do końca, którą dajecie prawdziwym użytkownikom. Resztę dobudowujemy, kiedy wiadomo, czego naprawdę używają.
Zaplecze i panel administracyjny
Aplikacja rzadko działa sama, więc piszemy też serwer, bazę danych i prosty panel w przeglądarce, w którym ktoś z biura zmieni cennik albo treść powiadomienia bez dzwonienia do nas. Albo podłączamy się do waszego systemu.
Przegląd cudzej aplikacji
Gdy poprzedni wykonawca zniknął albo aplikacja zbiera jedno-gwiazdkowe opinie, przeglądamy kod, zależności i konfigurację sklepów. Dostajecie spis problemów ułożony od najpilniejszych. Przegląd trwa zwykle kilka dni roboczych i kończy się rozmową, na której omawiamy każdy punkt.
Opieka po premierze
Apple i Google co roku zmieniają wymagania, a biblioteki się starzeją, dlatego proponujemy stały pakiet godzin na aktualizacje i drobne zmiany. Rozliczany co miesiąc. Obejmuje też pilnowanie certyfikatów, kluczy do powiadomień i terminów, w których sklepy wymagają nowszej wersji SDK.
Czego nie bierzemy, żeby nie marnować waszego czasu
Odmawiamy wtedy, gdy wiemy, że ktoś inny zrobi to lepiej albo że sam projekt budzi nasze wątpliwości. Lepiej powiedzieć to przy pierwszym telefonie.
- gier mobilnych i aplikacji z hazardem lub zakładami,
- samych stron internetowych bez części mobilnej,
- projektów wycenianych „na szybko” bez warsztatu,
- aplikacji, które mają zbierać informacje o użytkownikach bez ich wiedzy.
Jak wyceniamy pracę i dlaczego dopiero po warsztacie
Wycena przed warsztatem byłaby zgadywaniem, dlatego pierwszą kwotę podajemy dopiero wtedy, gdy wiemy, ile ekranów, integracji i ról użytkowników ma mieć aplikacja. Potem to już zwykła arytmetyka.
Każdy dwutygodniowy odcinek ma osobną kwotę i listę rzeczy, które mają być gotowe na jego koniec, więc w każdej chwili możecie zatrzymać projekt, płacąc tylko za zamknięte etapy. Tak jest uczciwiej dla obu stron. Opiekę po premierze rozliczamy inaczej: stały pakiet godzin w miesiącu, a niewykorzystane godziny przechodzą na kolejny miesiąc, choć tylko na jeden.
Co przygotować przed pierwszą rozmową
Nie potrzebujemy specyfikacji na czterdzieści stron, bo i tak piszemy ją razem na warsztacie. Wystarczy kilka rzeczy.
- Dwa, trzy zdania o tym, kto ma korzystać z aplikacji i w jakiej sytuacji.
- Listę systemów, z którymi aplikacja ma rozmawiać: sklep, magazyn, CRM, płatności.
- Zrzuty ekranu aplikacji, które się wam podobają albo irytują — jedno i drugie pomaga.
- Termin, który jest naprawdę sztywny, jeśli taki istnieje.
Umawiamy się telefonicznie: +48 22 834 60 26, od poniedziałku do piątku.