Apputveckling för företag som vill gå från idé till färdig produkt.

Det beror på omfattningen, och därför ger vi inga prislappar innan vi vet vad som ska byggas. Det som driver kostnaden är antalet funktioner, hur mycket design som krävs, om det behövs backend och adminsystem, antalet användarroller, integrationer mot externa system, betalningar och eventuella AI-funktioner. En avgränsad MVP med ett tydligt flöde kostar en bråkdel av en plattform med flera roller och integrationer. Så här gör vi istället: vi går igenom er idé, hjälper er skala ner till en meningsfull första version och lämnar en uppskattning av kostnad och tid för just den. Då vet ni vad ni tackar ja eller nej till.

En enkel app med ett tydligt huvudflöde går att få ut på några månader. En större plattform med flera användarroller, betalningar och integrationer tar längre tid. Det som framför allt påverkar tidsplanen är hur väl avgränsat scopet är, hur mycket backend som ska byggas, hur många externa system som ska kopplas in, och hur snabbt ni kan ge feedback under vägen. Oavsett storlek får ni något körbart tidigt – vi väntar inte till slutet med att visa. Lägg också till tid för granskning i App Store och Google Play innan lansering.

Ja. Vi bygger oftast i React Native, vilket innebär att iOS och Android delar samma kodbas. Ni får två appar men betalar inte för att bygga allt två gånger, och när en funktion ska ändras görs det på ett ställe. Vi publicerar i både App Store och Google Play. Om ni av budgetskäl vill börja på en plattform går det bra – men med React Native är besparingen mindre än många tror, så oftast är det värt att lansera på båda direkt.

React Native är ett ramverk från Meta för att bygga mobilappar. Kort förklarat skriver man appen en gång och kör den på både iOS och Android, med riktiga gränssnittskomponenter från respektive plattform – inte en webbsida i en app-förpackning. Det används av bland andra Instagram, Shopify och Discord. Fördelen för er är främst affärsmässig: en kodbas betyder kortare utvecklingstid, lägre underhållskostnad och att nya funktioner når båda plattformarna samtidigt. Det passar de flesta appar, men inte alla – behöver appen avancerad grafik, tung realtidsbearbetning eller djup hårdvaruåtkomst kan native vara rätt val. Vi säger till om vi tycker det.

Ja, och i de flesta projekt är det vi som gör det. En app är sällan bara ett gränssnitt – någonstans behöver data lagras, användare loggas in och affärslogik köras. Vi bygger databas, API:er, inloggning och behörigheter, adminsystem, betalningar, pushnotiser och integrationer mot era befintliga system. Har ni redan en backend eller ett affärssystem kopplar vi appen mot det istället. Att app och backend byggs av samma team gör att färre saker faller mellan stolarna.

Ja. Vi tar över appar som byggts av andra, både för löpande förvaltning och för större vidareutveckling. Vi börjar med att gå igenom kodbasen och ge er en ärlig bild: vad som är i gott skick, vad som behöver åtgärdas och vad det innebär att bygga vidare. Ibland är svaret att renovera stegvis, ibland att skriva om delar. Vi säger vilket vi tror på och varför – och om vi tycker att ni ska behålla er nuvarande leverantör säger vi det också.

Ja, vi tar hand om publiceringen. Det innefattar att sätta upp utvecklarkonton, förbereda butikstexter, skärmbilder och ikoner, hantera Apples och Googles granskningsprocess och skicka in uppdateringar löpande. Vi hanterar också sådant som integritetspolicy och de deklarationer om datainsamling som butikerna kräver. Konton och appar ska stå i ert företags namn – det är ni som äger närvaron i butikerna, inte vi.

Ni. Koden vi skriver åt er tillhör er, och det regleras i avtalet innan vi börjar. Ni får tillgång till repositoryt under projektets gång, inte bara vid leverans, och kontona hos App Store, Google Play och hostingleverantören står i ert namn. Skulle ni vilja ta över utvecklingen själva eller byta leverantör ska det gå att göra utan att förhandla med oss först. Vi tycker att inlåsning är ett dåligt sätt att behålla kunder.

Ja, och vi gör det när det löser ett verkligt problem. Vanliga användningsområden är att sammanfatta längre texter, läsa ut uppgifter ur dokument och kvitton, driva en assistent som svarar utifrån ert eget innehåll, ge rekommendationer eller automatisera manuell handpåläggning. Vi går igenom var i ert flöde det faktiskt sparar tid, och är lika tydliga med var det inte gör det. Vi tar också upp kostnad per anrop, svarstider och hur känsliga data hanteras innan vi bygger.