Pliki cookies

Pliki cookies niezbędne zapewniają działanie strony. Analityczne i reklamowe (statystyki odwiedzin, pomiar skuteczności reklam) włączamy tylko za Państwa zgodą, którą można w każdej chwili zmienić lub wycofać w „Ustawieniach cookies” w stopce strony. Więcej: polityka cookies, polityka prywatności.

Jak wybieramy technologię do projektu?

Kto będzie używał aplikacji

Zaczynamy od pytania, kto będzie używał aplikacji i jak długo ma żyć, a nie od ulubionego frameworka. Aplikacja dla klientów zewnętrznych musi działać na Androidzie i iOS, narzędzie dla pracowników z firmowymi telefonami często wystarczy na jedną platformę.

Sprzęt i integracje

Drugie pytanie dotyczy sprzętu i integracji. Bluetooth, NFC, praca w tle, kamera z analizą obrazu albo wymagania Apple dotyczące danych zdrowotnych przesuwają wybór w stronę kodu natywnego. Integracje z ERP, CRM i płatnościami decydują o tym, jak rozbudowany będzie backend.

Koszt budowy i utrzymania

Trzecie pytanie jest finansowe. Jeden kod na dwie platformy obniża koszt budowy i utrzymania, dwie aplikacje natywne kosztują więcej, ale dają pełną kontrolę nad każdą z nich. Każdą z tych decyzji opisujemy w wycenie wprost, razem z tym, z czego rezygnujesz.

Te same zasady na każdym projekcie

Na wszystkich projektach stosujemy te same zasady: automatyczne testy i budowanie wersji, dokumentacja techniczna, a po zapłacie ostatniej faktury - przekazanie kodu, praw autorskich i dostępów. Szczegóły dla aplikacji mobilnych opisujemy na stronie tworzenie aplikacji mobilnych, a dla systemów webowych na stronie aplikacje webowe na zamówienie.

Rekomendację technologiczną dostajesz razem z wyceną - cały przebieg opisujemy na stronie proces współpracy.

Technologie, z których korzystamy

Przy każdej piszemy, kiedy ją polecamy i kiedy odradzamy. Nie ma technologii dobrej do wszystkiego, a wybór zły dla danego projektu kosztuje więcej niż sama budowa.

Aplikacja Germania Mint - zestawienie ekranów: wybór języka, weryfikacja i historia produktów

Flutter - jeden kod na Android i iOS

Większość naszych aplikacji mobilnych od kilku lat powstaje we Flutterze. Polecamy go, gdy aplikacja ma działać na obu platformach, a budżet ma wystarczyć na backend i panel administracyjny.

Kiedy nie: gry 3D, aplikacje oparte głównie o funkcje systemowe

Smartfon z aplikacją VG Lock przy drzwiach z zamkiem elektronicznym

Kotlin - natywne aplikacje na Androida

Jetpack Compose, praca offline, Bluetooth, NFC i usługi działające w tle. Polecamy, gdy aplikacja jest tylko na Androida albo mocno korzysta ze sprzętu.

Kiedy nie: aplikacja potrzebna od razu także na iOS

Dłonie trzymające smartfon z aplikacją hotelową, w tle gość w pokoju hotelowym

Swift - natywne aplikacje na iPhone’a i iPada

SwiftUI, HealthKit, ARKit, Apple Pay i przejście przez weryfikację App Store. Polecamy, gdy aplikacja ma korzystać z funkcji dostępnych tylko w ekosystemie Apple.

Kiedy nie: ograniczony budżet na dwie platformy

Dłonie trzymające smartfon z ekranem logowania aplikacji MASTER Climate Solutions

Laravel i PHP - backend, API, panele

Backend większości naszych aplikacji mobilnych i webowych: API, panele administracyjne, kolejki zadań, integracje z ERP i płatnościami.

Kiedy nie: zespół klienta utrzymuje wyłącznie stos JavaScript

Kosmetyki naturalne na blacie i ekran aplikacji APH Serwis z bestsellerami

React i Node.js - aplikacje webowe i panele

Rozbudowane interfejsy webowe, platformy B2B i panele z dużą liczbą interakcji. React łączymy z backendem w Laravelu albo w Node.js, zależnie od projektu.

Kiedy nie: prosty panel, który szybciej zbudujemy w Livewire

Urządzenie do badania skóry, smartfon z wynikami DermoSI i kobieta dotykająca twarzy

AI - modele językowe, RAG, agenci, n8n

Asystenci odpowiadający na podstawie dokumentów firmy, odczyt dokumentów, agenci obsługujący zgłoszenia i analiza obrazu w aplikacjach mobilnych. Z kosztami i ograniczeniami podanymi wprost.

Kiedy nie: proces da się opisać regułami - wtedy wystarczy automatyzacja

Dłoń z pomalowanymi paznokciami i smartfon z ekranem logowania aplikacji Nails Room

Python - uczenie maszynowe, analiza obrazu i danych

Modele uczenia maszynowego, analiza obrazu, przetwarzanie danych i backendy w Django. Użyliśmy go m.in. w DermoSI, Nails Room i aplikacji AI dla BIOFARM.

Kiedy nie: typowe API i panel administracyjny - szybciej zbudujemy je w Laravelu

Logo HookMyRide na granatowym tle i dwa telefony z aplikacją: pulpit motocyklisty i mapa z motocyklistami w pobliżu

Rust - wydajne usługi i narzędzia

Usługi, które muszą szybko przetwarzać dużo danych przy małym zużyciu pamięci: przetwarzanie plików, komunikacja z urządzeniami, moduły wymagające wysokiej wydajności. Przykład: aplikacja dla motocyklistów HookMyRide (Rust i MQTT).

Kiedy nie: typowa aplikacja biznesowa, w której liczy się czas budowy, a nie milisekundy

Tablet z ekranem logowania aplikacji Koszyk marzeń na biurku

HTML, CSS i JavaScript - strony i interfejsy webowe

Strony firmowe, panele, widoki aplikacji hybrydowych i PWA - szybkie i czytelne na każdym urządzeniu. Przykłady: Nove Życie, Giełda Rolnicza, Koszyk Marzeń.

Kiedy nie: rozbudowany interfejs z dużą liczbą interakcji - wtedy React

Kobieta z torbą zakupów i ekran aplikacji Ratuj Jedzenie z ofertą sklepu

Livewire - panele i formularze w Laravelu

Interaktywne panele, formularze i listy bez osobnej aplikacji frontendowej - wszystko w jednym projekcie Laravel. Przykłady: Ratuj Jedzenie, aplikacja dla kierowców i przewoźników.

Kiedy nie: praca offline albo interfejs z bardzo dużą liczbą interakcji - wtedy React lub aplikacja mobilna

Rysunek nowoczesnego pociągu białą linią na niebieskim tle, obok logo Stadler

MySQL i PostgreSQL - bazy danych

Projekt struktury danych, zapytania SQL, migracje, kopie zapasowe i optymalizacja wolnych zapytań - pod każdą aplikację i każdy panel, które budujemy. Przykład: aplikacja do szkolenia maszynistów dla Stadler.

Kiedy nie: dane bez stałej struktury, np. logi zdarzeń - wtedy baza dokumentowa albo wyszukiwarka

Logo educhmura i dwa telefony z aplikacją: ekran powitalny dla rodziców i pulpit z materiałami na turkusowym tle

C# i .NET - aplikacje na Windows i systemy POS

Aplikacje desktopowe na Windows i systemy sprzedaży (POS) dla punktów obsługi klienta. Przykłady: aplikacja na Windows dla educhmury, Jarocin POS, DermoSI POS.

Kiedy nie: aplikacja ma działać także na Macu i w przeglądarce - wtedy aplikacja webowa

Najczęściej zadawane pytania o technologie

Jeśli aplikacja ma działać na Androidzie i iOS, a jej funkcje to formularze, listy, płatności, mapy i powiadomienia, wybieramy Fluttera: jeden kod, jeden zespół, niższy koszt utrzymania. Kod natywny w Kotlinie i Swifcie polecamy, gdy aplikacja intensywnie korzysta ze sprzętu, działa w tle albo ma być rozwijana latami przez dwa osobne zespoły. Rekomendację uzasadniamy w wycenie.

Tak, najmocniej przy aplikacjach mobilnych. Dwie aplikacje natywne to dwa kody do napisania, przetestowania i utrzymania, więc kosztują więcej niż jedna aplikacja we Flutterze o tym samym zakresie. Aplikacje realizujemy od 15 000 zł netto, a większe wdrożenia wyceniamy indywidualnie. W wycenie pokazujemy koszt wybranego wariantu i różnicę względem alternatywy, żebyś mógł świadomie zdecydować.

Najczęściej w Laravelu na PHP - w nim powstał backend większości naszych realizacji, m.in. aplikacji dla Germania Mint i Gminy Jarocin. Panele budujemy w Livewire albo w React, zależnie od liczby interakcji. Node.js wybieramy przy komunikacji w czasie rzeczywistym i przy integracjach, w których zespół klienta pracuje wyłącznie w JavaScripcie. Bazy danych to zwykle MySQL albo PostgreSQL.

Tak, jeśli jest w technologii, którą znamy: Flutter, Kotlin, Java, Swift, React Native, Laravel, React. Zaczynamy od audytu kodu i dokumentacji, po którym dostajesz raport: co działa, co wymaga poprawy, co taniej napisać od nowa i ile to kosztuje. Jeśli technologia jest nam obca, mówimy to od razu, zamiast uczyć się na Twoim projekcie.

Zaktualizowano:

Napisz Zadzwoń