Aplikacje na zamówienie dla Twojej firmy

Prowadzenie firmy to codzienne zarządzanie zadaniami, klientami, zamówieniami i ludźmi. Przez pierwsze lata wystarczają do tego gotowe narzędzia — arkusz, prosty CRM, system fakturowania. W pewnym momencie przestają: dane trzeba przepisywać między systemami, część procesu żyje w czyjejś głowie, a każde nowe narzędzie dokłada kolejny abonament.

Wtedy pojawia się pytanie o aplikację na zamówienie — zbudowaną pod Wasz proces, a nie pod przeciętnego klienta producenta SaaS. Ten tekst wyjaśnia, jakie aplikacje buduje się dla firm, ile to kosztuje, jak przebiega projekt i po czym poznać, że to właśnie ten moment.

Aplikacje na zamówienie (inaczej: dedykowane aplikacje dla firm) to oprogramowanie zaprojektowane i zbudowane pod konkretną firmę i jej procesy. W odróżnieniu od gotowego produktu w abonamencie to nie firma dopasowuje się do narzędzia, tylko narzędzie do firmy.

W praktyce spotkasz trzy podejścia, które łatwo pomylić:

• Gotowa aplikacja (SaaS) — ta sama dla wszystkich, płatna w abonamencie. Wdrożenie w dniach, zero elastyczności.
• Gotowa aplikacja z konfiguracją — CRM lub ERP dostosowany polami, workflowami i integracjami. Wciąż cudzy produkt, nagięty do Waszych procesów.
• Aplikacja na zamówienie — budowana pod Wasz proces. Wy decydujecie o zakresie i jesteście właścicielem kodu, ale też Wy ponosicie koszt utrzymania.

Granica między drugim a trzecim podejściem bywa cienka. Jeśli konfiguracja gotowego narzędzia zajmuje miesiące i kończy się listą rzeczy, „których się nie da” — to zwykle sygnał, że jesteście już po stronie aplikacji dedykowanej.

Decyzja jest prostsza, niż się wydaje, jeśli sprowadzić ją do rachunku. Aplikacja na zamówienie opłaca się wtedy, gdy roczny koszt obecnego stanu — licencje, godziny tracone na ręcznych obejściach i procesy, których nie realizujecie, bo narzędzie nie pozwala — przekracza roczny koszt własnego systemu, czyli budowę rozłożoną na co najmniej trzy lata plus utrzymanie.

Trzy sygnały, że warto policzyć:

1. Ktoś w firmie prowadzi arkusz „na boku”, bo dwa systemy nie rozmawiają ze sobą — i tylko ta osoba wie, jak on działa.
2. Płacicie za kilka narzędzi, z których każde robi 30% tego, czego potrzebujecie, a reszta jest przepisywana ręcznie.
3. Nie realizujecie jakiegoś procesu, bo „system tego nie obsługuje” — raportu, oferty, obsługi klienta w określony sposób.

Jeśli żaden z tych sygnałów nie występuje, prawdopodobnie gotowe narzędzie wystarczy. Pełny rachunek z przykładem liczbowym i arkuszem do wypełnienia znajdziesz w naszym przewodniku po oprogramowaniu na zamówienie.

Większość firm nie potrzebuje na start wszystkich trzech. Prosta zasada: zacznij od tego, gdzie proces dziś boli najbardziej, i od najprostszej technologii, która ten ból usuwa.

Aplikacja internetowa (webowa) to najczęściej właściwy pierwszy krok. Działa w przeglądarce na każdym urządzeniu, nie wymaga publikacji w sklepach ani instalacji, a jedna wersja obsługuje biuro, magazyn i klienta. Portal klienta, panel zamówień, system rezerwacji, narzędzie dla działu obsługi — to prawie zawsze aplikacja webowa.

Aplikacja mobilna ma sens, gdy użytkownik naprawdę pracuje z telefonem: kurier w terenie, serwisant robiący zdjęcia i skanujący kody, klient, który ma dostać powiadomienie. Jeśli aplikacja ma być używana głównie przy biurku, wersja mobilna to koszt bez zwrotu. Szczegółowo porównujemy oba podejścia w tekście aplikacja webowa czy mobilna.

Program na zamówienie do pracy wewnętrznej — obsługa zamówień, produkcja, magazyn — to zwykle aplikacja webowa z panelem administracyjnym i integracjami z tym, co już macie: fakturowaniem, kurierami, płatnościami. Tu największą wartość dają nie ekrany, tylko to, że dane przestają być przepisywane ręcznie.

Częsty scenariusz, który sprawdza się w praktyce: aplikacja webowa jako pierwsza wersja, a mobilna dokładana po pół roku — kiedy wiadomo już, które funkcje ludzie faktycznie wykorzystują w terenie.

Cztery czynniki odpowiadają za większość różnic między wycenami:

Zakres funkcji. Nie liczba ekranów, tylko to, co za nimi stoi: role i uprawnienia, logika biznesowa, obsługa przypadków brzegowych. Panel z jedną tabelą i panel z workflow akceptacji to dwa różne projekty pod tą samą nazwą.

Integracje. Każdy zewnętrzny system — płatności, ERP, kurier, API partnera — to cudza dokumentacja, limity i testy na środowisku, którego nie kontrolujecie. Jedna trudna integracja potrafi podwoić czas projektu.

Platformy. Aplikacja webowa to jeden produkt. Aplikacja mobilna na Androida i iOS to — w podejściu cross-platform — jeden kod na dwie platformy, ale wciąż dwa sklepy, dwa procesy publikacji i dwa zestawy testów.

Utrzymanie. W publikowanych przykładach około 15% wartości wdrożenia rocznie — aktualizacje, poprawki, reagowanie na awarie. To osobna pozycja w budżecie, nie dodatek.

Jeśli interesuje Cię przede wszystkim aplikacja mobilna, szczegółowy rozkład kosztów — z realnymi widełkami dla MVP i produktu z panelem — opisaliśmy w tekście ile kosztuje aplikacja mobilna.

Najczęstszy błąd przy zamawianiu aplikacji to próba rozwiązania wszystkiego naraz. Duży zakres oznacza długi projekt, w którym założenia z początku dezaktualizują się przed końcem — a rozrost zakresu w projektach IT pozostaje niewidoczny do momentu, w którym staje się finansowo dotkliwy.

Rozsądniejsza droga: wybrać jeden proces, który boli najbardziej, zbudować dla niego najmniejszą działającą wersję (MVP), zmierzyć efekt i dopiero na tej podstawie rozszerzać. Mniejszy zakres to nie mniejsza ambicja, tylko mniejsza powierzchnia ryzyka.

Tak powstał na przykład sklep Bezuma: pierwsza działająca wersja w trzy tygodnie, kolejne funkcje dokładane na działającym systemie. A DetailingFlow — system dla studiów detailingu — zaczął się od jednego studia i jednego procesu rezerwacji, zanim stał się platformą.

Pracujemy z firmami z całej Polski, ale biuro mamy w Dąbrówce pod Poznaniem — jeśli wolisz omówić projekt na spotkaniu, jesteśmy w zasięgu. Dla firm z Poznania i okolic budujemy aplikacje mobilne oraz dedykowane oprogramowanie — od analizy, przez MVP, po utrzymanie.

Zapisy, które warto mieć w umowie z wykonawcą — prawa autorskie, kod źródłowy, odbiory, zakończenie współpracy — omawiamy osobno w tekście umowa z software house'em.