iOS- och Android-appar
En kodbas som ger två riktiga appar, med det plattformsspecifika gjort där det märks: navigation, gester, notiser och den känsla som skiljer en app från en inbäddad webbsida.
En app är den mest krävande produkten ett företag kan beställa. Den granskas av två butiker, den uppdateras hos användaren bara om användaren vill, den ska fungera med dålig uppkoppling, den ska hantera notiser, behörigheter och betalningar — och den jämförs varje dag med de bäst byggda apparna i telefonen, inte med konkurrentens.
Vi bygger appar som klarar den jämförelsen. Det börjar med att avgränsa det första flödet hårt: vad användaren ska kunna göra på trettio sekunder, och vad som kan vänta till version två. Det som byggs blir då färdigt i stället för nästan färdigt, och lanseringen blir ett datum i stället för en förhoppning.
De flesta appar vi bygger är inte ensamma. Det finns en webbpanel där verksamheten sköter innehåll och ärenden, ett API mellan dem och ofta ett befintligt system som redan äger sanningen om kunder eller lager. Vi bygger hela den kedjan, vilket är skälet till att den håller ihop.
Omfattningen sätts per projekt. Det här är delarna vi arbetar med.
En kodbas som ger två riktiga appar, med det plattformsspecifika gjort där det märks: navigation, gester, notiser och den känsla som skiljer en app från en inbäddad webbsida.
Servern bakom appen: konton, data, synk, behörigheter och den administration som gör att verksamheten kan sköta sig själv utan utvecklare.
Gränssnitt ritade för en tumme i rörelse. Vi testar huvudflödet i en klickbar prototyp innan det byggs, eftersom en omritning i design kostar en dag och i kod en vecka.
App Store och Google Play: konton, certifikat, butikstexter, skärmbilder, integritetsdeklarationer och granskningen — som är där oförberedda projekt tappar veckor.
Push-notiser som är värda att ta emot, köp i appen och abonnemang, kortbetalningar, Swish, BankID och kopplingar mot de system ni redan kör.
Appar slutar fungera av sig själva när operativsystemen uppdateras. Vi håller versioner, beroenden och butikskrav aktuella, och mäter vad användarna faktiskt gör.
Omfattningen styr priset, inte timpriset. Det som driver kostnaden är antalet användartyper, om appen behöver egen inloggning och synk, om betalningar ingår, hur många externa system den ska prata med och hur mycket som måste fungera utan uppkoppling. En avgränsad app med ett tydligt huvudflöde är ett helt annat projekt än en plattform med flera roller och integrationer. Vi går igenom omfattningen på ett kostnadsfritt möte och återkommer med ett intervall och skälen bakom det.
En avgränsad första version ligger vanligtvis på några månader från start till butik. Det som avgör är hur väl version ett är avgränsad — inte hur snabbt någon kodar. Därför lägger vi tid på att definiera det första flödet innan utvecklingen börjar, och därför blir omfattningen oftast mindre efter första mötet än före.
Ja, och normalt från en gemensam kodbas. Det ger två riktiga appar till en kostnad närmare en än två, och skillnaderna mellan plattformarna hanteras där de faktiskt märks för användaren. När ett projekt kräver djup integration mot en enskild plattform bygger vi nativt i Swift eller Kotlin i stället, och säger varför.
Ja, och konton och certifikat registreras i ert namn — inte i vårt. Vi förbereder butikstexter, skärmbilder, integritetsdeklarationer och åldersgränser, och hanterar granskningen. Det är det steg som oftast överraskar: granskningen avslår gärna på detaljer som är billiga att förbereda och dyra att upptäcka på lanseringsdagen.
Ja. Koden, kontona och all data är era, och överlämnas i ett skick där en annan utvecklare kan ta vid — repo, dokumentation, miljöer och byggkedja. Det är också vad vi ber om när vi tar över en app från någon annan, och den vanligaste orsaken till att ett övertagande blir dyrare än det borde är att det inte fanns.
Ja. Vi börjar med en genomgång av koden, beroendena, byggkedjan och butikskontona, och rapporterar vad som är värt att behålla, vad som måste bytas och vad som är akut. Du får bilden innan vi föreslår ett arbete — ibland är svaret att appen ska förvaltas vidare, inte byggas om.
Lanseringen är oftast halvvägs. Operativsystemen uppdateras varje år och butikernas krav ändras, så en app som inte förvaltas slutar fungera av sig själv inom ett par år. Vi håller den aktuell, mäter vad användarna faktiskt gör och bygger vidare utifrån det i stället för utifrån önskelistan.
Boka ett kostnadsfritt möte. Vi går igenom idén, vad version ett bör innehålla och vad ett första steg innebär.