Budujemy aplikacje dla zespołów pracujących w terenie, dla klientów firmy i dla procesów, które dziś trzymają się na arkuszu i na papierze. Ustalony zakres, stała cena, zespół z Krakowa, z którym rozmawiacie bezpośrednio.
To rzadko wygląda jak pomysł na aplikację. Zwykle jest to konkretne miejsce, w którym firma traci czas albo dane, a wszyscy w środku dobrze wiedzą, gdzie ono jest.
Technik, monter albo kontroler wypełnia formularz na kartce, robi zdjęcia telefonem i wieczorem przepisuje wszystko do systemu. Część rzeczy ginie po drodze, a biuro dowiaduje się o problemie dzień później.
Firma ma stronę i panel w przeglądarce, a klienci chcą rezerwować, zgłaszać i sprawdzać status z telefonu. Strona mobilna działa, ale nie daje powiadomień ani wygody, której oczekują.
Cały obieg zleceń albo grafik siedzi w pliku, który zna jedna osoba w firmie. Rośnie liczba wierszy, rośnie liczba wyjątków i każda zmiana wymaga telefonu do tej jednej osoby.
Firmy często traktują je zamiennie, a różnią się w niemal każdym wymiarze, który wpływa na termin i budżet. Aplikacja wewnętrzna ma znanych użytkowników, konkretny proces i zwykle musi się połączyć z tym, co już działa w firmie. Aplikacja dla klientów ma nieznanych użytkowników, wymaga publikacji w sklepach i przechodzi przez recenzję Apple oraz Google.
Najczęściej okazuje się, że firma potrzebuje najpierw jednej z nich, a nie obu naraz. Ta rozmowa jest warta odbycia przed wyceną, bo przesuwa termin pierwszej wersji o kilka tygodni w jedną albo w drugą stronę.
Prawie każda firma, z którą rozmawiamy, ma już coś, co działa. System serwisowy, program magazynowy, własną bazę klientów albo zestaw arkuszy. Aplikacja rzadko ma to zastąpić. Ma to uzupełnić o to, czego nie da się zrobić przy biurku.
Dlatego pierwsze pytanie na rozmowie dotyczy nie ekranów, tylko tego, gdzie dziś mieszkają wasze dane i kto ma do nich dostęp. Odpowiedź decyduje o połowie wyceny.
Najczęstszym powodem poślizgu w projektach dla firm nie jest kod, tylko czas oczekiwania na dostęp do systemu, z którym aplikacja ma się połączyć.
Opowiedzcie, gdzie dziś ucieka czas. Na rozmowie przejdziemy przez proces i powiemy, czy aplikacja jest tu w ogóle właściwym narzędziem.
Umów rozmowęDla jednej firmy to możliwość podejrzenia listy zleceń w piwnicy. Dla drugiej wypełnienie protokołu, zrobienie zdjęć i wysłanie ich, kiedy telefon wróci do sieci. Trzecia potrzebuje aplikacji, która całą zmianę pracuje offline, a synchronizuje się raz dziennie. To trzy różne projekty i trzy różne budżety, więc rozstrzygamy to na starcie, a nie w połowie prac.
Dane pobrane wcześniej są dostępne bez sieci. Aplikacja nic nie zapisuje, więc nie ma konfliktów. Najtańszy wariant i często wystarczający.
Technik wypełnia formularze i robi zdjęcia bez zasięgu, a wszystko wychodzi później. Trzeba rozstrzygnąć kolejność, powtórzenia i to, co się dzieje, gdy dwie osoby zmienią to samo.
Sieć jest dodatkiem, nie warunkiem. Aplikacja ma własną bazę na urządzeniu i pełny mechanizm synchronizacji. Najdroższy wariant, uzasadniony przy pracy w miejscach bez zasięgu.
Dwa projekty wewnętrzne dla firm, które miały już działający proces i chciały przenieść go z papieru i arkuszy do jednego narzędzia.
Zrzut TimeFixAplikacja dla techników i panel dla biura. Zlecenia, czas pracy i zdjęcia rejestrowane na miejscu, zamiast notatnika i wieczornego przepisywania do systemu.
Zrzut WorklySystem klasy ERP dla produkcji, zbudowany we Flutterze na Supabase. Zmiany, ewidencja pracy i raporty w jednym interfejsie, który działa tak samo na telefonie i na komputerze.
Pracujemy w stałej cenie, więc zakres musi być domknięty, zanim ktokolwiek napisze linijkę kodu. To wymaga od nas kilku godzin rozmów na początku i zdejmuje z was ryzyko rachunku, który rośnie razem z projektem.
Projekty dla firm rzadko przeciągają się z powodów technicznych. Przeciągają się, bo po stronie klienta czegoś zabrakło w momencie, w którym było potrzebne. Te cztery rzeczy załatwiają większość ryzyka.
Pierwsza działająca wersja zwykle powstaje w 8 do 12 tygodni. Aplikacja obsługująca cały proces w terenie, z integracjami i pracą bez zasięgu, to zazwyczaj 12 do 22 tygodni.
Nie musi, ale przy Flutterze i React Native nie ma powodu, żeby dzielić. Jeden zespół buduje obie wersje z jednego kodu, więc drugi system kosztuje ułamek pierwszego, nie drugie tyle.
Zwykle tak. Jeśli system ma API, sprawdzamy dokumentację i limity. Jeśli nie ma, zostaje eksport, import albo połączenie z bazą, i wtedy wyceniamy to jako osobny element zakresu.
Wyceniamy zmianę osobno i decydujecie, czy wchodzi teraz, czy po pierwszym wydaniu. Ustalony zakres zostaje w stałej cenie, więc nowa funkcja nigdy nie zjada budżetu tego, co już obiecane.
To zależy od tego, co wasi ludzie robią w miejscach bez zasięgu. Podgląd danych jest tani, praca offline z zapisem i synchronizacją kosztuje wyraźnie więcej. Ustalamy to na pierwszej rozmowie.
Pracujemy z firmami z całej Polski i z zagranicy, zdalnie oraz na spotkaniach na miejscu, kiedy projekt tego wymaga. Więcej o zespole znajdziecie na stronie software house Kraków i w opisie usługi tworzenie aplikacji mobilnych.
Rozmawiamy o waszym obecnym procesie i systemach, z których korzystacie. Na tej podstawie przygotowujemy pisemny zakres pierwszej wersji wraz z terminem i stałą ceną.

30 minut konkretnej rozmowy o twoich celach.