Vi hjälper företag och startups att utveckla appar för iOS och Android – från första idé till publicerad app i App Store och Google Play. Ni får ett team som tar ansvar för hela kedjan: UX, app, backend och vidareutvecklingen efter lansering.
De flesta som hör av sig har en idé och en verksamhet att sköta – inte ett tekniskt underlag. Det räcker. Vi tar hand om stegen däremellan och håller ihop ansvaret så att ni har en part att vända er till, inte fyra.
Det betyder att samma team gör kravarbetet, ritar gränssnittet, bygger appen och backend, testar, publicerar och fortsätter utveckla efteråt. Ni behöver inte samordna en designbyrå med en apputvecklare och en driftleverantör.
Vi går igenom vad appen ska lösa, för vem, och vad som faktiskt måste finnas i version ett. Ofta är det färre funktioner än man tror.
En klickbar prototyp innan vi skriver produktionskod. Ni ser flödena och kan ändra medan det fortfarande är billigt att ändra.
Gränssnitt som följer konventionerna på iOS och Android. En app ska kännas bekant direkt, inte kräva en introduktion.
Själva bygget i React Native och TypeScript. Vi jobbar i sprintar och ni får något körbart i handen längs vägen.
Databas, inloggning, serverlogik och integrationer mot de system ni redan använder. Vi bygger hela kedjan, inte bara skalet.
Vi testar på riktiga enheter, inte bara i simulator. Buggar som hittas före lansering är betydligt billigare än de som hittas efter.
Vi hanterar App Store och Google Play – konton, granskningsprocess, butikstexter och bilder. Ni behöver inte lära er reglerna.
Efter lansering fortsätter arbetet: nya funktioner, uppdateringar och förbättringar utifrån hur appen faktiskt används.
Era användare finns på båda plattformarna, och att bygga två separata appar innebär i praktiken två projekt att betala för och underhålla. Vi bygger därför oftast i React Native, där iOS och Android delar samma kodbas.
Affärsmässigt betyder det kortare väg till lansering, en app att underhålla istället för två, och att en ny funktion når alla användare samtidigt. Rättar vi en bugg är den rättad på båda plattformarna.
Men React Native är inte alltid rätt svar. Ska appen göra tung bildbehandling, avancerad grafik eller använda hårdvara på ett djupt sätt kan native vara bättre. Vi tittar på vad produkten faktiskt ska göra och rekommenderar därefter – även när det betyder mer arbete för oss.
Samma upplägg oavsett projektets storlek. Ni ska aldrig behöva undra var i processen vi är eller vad som händer härnäst.
30 minuter. Ni berättar vad ni vill bygga, vi ställer frågor och säger om vi är rätt partner. Kostar ingenting.
Vi går på djupet i funktioner, användare och integrationer. Resultatet är ett avgränsat scope för första versionen.
Flöden och skisser blir en klickbar prototyp. Ni kan känna på appen innan en rad produktionskod är skriven.
Sprintar om 1–2 veckor med app och backend parallellt. Ni ser en körbar version efter varje sprint.
Test på riktiga enheter, både iOS och Android. Ni testar också själva och vi rättar innan lansering.
Vi publicerar i App Store och Google Play och tar hand om granskningen tills appen är uppe.
Vi mäter, rättar och bygger vidare. Många kunder fortsätter med oss löpande efter lansering.
Nästan alla appidéer är för stora från början. Det är inte ett problem – det är normalt. Men att bygga hela visionen direkt innebär att ni betalar för funktioner som ingen ännu vet om de kommer att användas.
Vi föreslår istället att ni börjar med en MVP: den minsta version som löser huvudproblemet för era användare. Ofta räcker ett flöde. Den kommer ut snabbare, kostar mindre och – viktigast – ger er riktig information.
Innan vi bygger gör vi en klickbar prototyp som ni och gärna några riktiga användare får testa. Missförstånd som upptäcks i en prototyp kostar en eftermiddag att rätta. Samma missförstånd i en lanserad app kostar betydligt mer.
Efter lansering tittar vi på hur appen används och bygger vidare därifrån. Det som står i vägen för användarna prioriteras först – funktioner som ingen efterfrågar kan vänta, eller strykas.
Appen är den del användarna ser. Under den ligger oftast lika mycket arbete: data som ska lagras, användare som ska loggas in och system som ska prata med varandra. Vi bygger den delen också – och kopplar gärna appen mot det ni redan har.
E-post, BankID eller SSO. Olika behörigheter för användare, personal och administratörer.
En struktur som håller när datamängden växer och nya funktioner tillkommer.
Ett backoffice där ni själva hanterar innehåll, användare och beställningar utan att ringa oss.
Stripe, Klarna eller köp i appen – beroende på vad ni säljer och vilka regler som gäller.
Koppling mot affärssystem, CRM, bokning, lager eller den hårdvara ni redan använder.
Notiser som ger användaren ett skäl att komma tillbaka, utan att bli störande.
Mätning av vad användarna faktiskt gör i appen, som underlag för vad ni bygger härnäst.
Hosting, loggar och larm när något går fel – gärna innan era användare hinner märka det.
Behöver ni mer än en app? Vi jobbar även med webbplattformar och systemutveckling – ofta som en del av samma lösning.
AI är värt att bygga in när det tar bort ett moment som användarna faktiskt tycker är jobbigt. Oftast handlar det om text, dokument eller manuell handpåläggning – inte om att lägga till en chattbubbla.
Några exempel: en assistent som svarar på frågor utifrån ert eget material, sammanfattningar av längre texter, uppgifter som läses ut ur kvitton och dokument så att användaren slipper knappa in dem, rekommendationer baserade på tidigare beteende, eller automatisering av steg som idag görs för hand.
Vi går igenom var i ert flöde det finns verklig tid att spara, och säger till när svaret är att en vanlig funktion löser problemet bättre. Innan vi bygger tar vi också upp kostnad per anrop, svarstider och hur känsliga data hanteras – det är de frågor som brukar avgöra om en AI-funktion håller i produktion.
Vi sätter inga prislappar innan vi vet vad som ska byggas – det skulle bara vara en gissning. Men vi kan vara tydliga med vad som driver kostnaden, så att ni förstår vad ni betalar för.
Så här brukar vi göra istället: vi går igenom er idé tillsammans, hjälper er avgränsa till en första version som faktiskt är värd att bygga, och lämnar en uppskattning av kostnad och tid för just den. Är scopet tydligt kan vi ofta ge fast pris. Är det mer osäkert jobbar vi per sprint – och då är vi öppna med att det är därför.
Det ni får ut av det första samtalet är användbart även om ni väljer någon annan: en rimlig bild av vad er app skulle kosta att bygga.
Det ärliga svaret är att det beror på omfattningen. En app med ett tydligt huvudflöde är ett betydligt kortare projekt än en plattform med flera roller, betalningar och integrationer mot befintliga system.
Det som påverkar tidsplanen mest är hur väl avgränsad första versionen är, hur mycket backend som ska byggas från grunden, hur många externa system som ska kopplas in, och hur snabbt ni kan ge besked när vi behöver ett beslut. Den sista punkten underskattas ofta – ett projekt står sällan still på grund av kod.
Räkna också med granskningstiden hos Apple och Google innan lansering. Vi lägger in den i planen från början så att den inte kommer som en överraskning.
Vi ger inga exakta löften innan vi vet vad som ska byggas. Däremot får ni en tidsplan när scopet är satt, och något körbart i handen långt innan slutdatumet.
Vi väljer teknik som gör appen snabb att bygga nu och möjlig att bygga vidare på om två år. Ni behöver inte kunna det här – men ni ska veta varför vi valt det vi valt.
En kodbas för iOS och Android. Kortare utvecklingstid och en app att underhålla istället för två.
Typad kod fångar fel redan i editorn. Det gör kodbasen tryggare att ändra i om ett år.
För webbdelar, adminsystem och landningssidor som hör ihop med appen.
Tydliga gränssnitt mellan app och server gör det enklare att bygga vidare utan att riva upp allt.
Relationsdatabas med migreringar, så att datamodellen kan växa kontrollerat.
Skalbar drift med automatiska deployer, backuper och övervakning från start.
Lanseringsdagen är början på produktens liv, inte slutet på projektet. Det är då ni får veta hur appen faktiskt används – och det stämmer sällan exakt med planen.
Vi övervakar drift och krascher, rättar buggar som dyker upp, och håller appen uppdaterad när Apple och Google släpper nya versioner av iOS och Android. Det sista är inte valfritt: en app som inte underhålls slutar förr eller senare att fungera.
Parallellt bygger vi vidare. Nya funktioner, förbättringar av det som skaver, och löpande uppdateringar till App Store och Google Play. Vad som prioriteras bestämmer ni – vi bidrar med underlag och en rekommendation.
Vi förvaltar gärna appen långsiktigt som er utvecklingspartner, med tydliga avtal om vad som ingår. Vill ni hellre bygga upp ett eget team hjälper vi er med överlämningen. Båda vägarna är okej – vi bygger inte in er hos oss.
Tre projekt som visar hur vi jobbar – från lojalitetsapp till komplett beställningssystem.
Ingen projektledare som vidarebefordrar frågor. Personen som svarar på ert mail är samma person som skriver koden.
Ni behöver inte kunna bedöma arkitektur eller teknikval. Vi föreslår, motiverar och står för besluten.
Slipper samordna en appbyrå med en backendleverantör. Hela kedjan byggs av ett team som ser helheten.
Ni får något att klicka på tidigt. Diskussionen handlar om en riktig app, inte om ett dokument.
Om en funktion inte bär sin kostnad, eller om projektet inte passar oss, säger vi det. Hellre tidigt än efter fakturan.
Vi förvaltar gärna appen efter lansering – eller hjälper er bygga upp ett eget team. Båda vägarna är okej.
Mer om hur vi jobbar och vilka vi är hittar ni på om oss.
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.
Ett kort möte där vi går igenom funktioner, teknik och nästa steg. Ni får en rimlig bild av omfattning och kostnad - även om ni väljer någon annan.