Vi får ofta förfrågningar om appar och apputveckling där själva underlaget är av typen ” jag har en mark och vill ha en byggnad på denna” ingenstans framgår om det är ett nytt “Burj Khalifa” som skall byggas eller om det är en “friggebod”.
Detta gör att svaren man som kund får på en sådan förfrågan kan skilja sig avsevärt både i produkt och pris samt naturligtvis i funktion. Tyvärr finns det även i denna bransch de som specialiserat sig på att utnyttja situationen och erbjuda något som på ytan ser fantastiskt bra ut men sedan visar sig vara en investering i ett byggprojekt utan ände. Ofta ser vi att dessa anbud är uppbyggda så att en del av ersättningen avser förstudien och det är det enda projektet kommer att leverera eller så levererar man en lösning som efter bara någon månad kräver omfattande uppdateringar som lång överstiger grundpriset.
Några grundläggande tips vid upphandling av appar förutom det uppenbara, vad appen skall göra och för vem.
Operativsystem.
Var tydlig med vad det är upphandlingen avser. Är det appar för smartphones, ange vilka operativsystem som appen skall fungera för och ange versioner. Ett vanligt misstag är att skriva att apparna skall fungera även i surfplattor av olika slag vilket de flesta appar gör hjälpligt men utan att ange om det är en specifik app för iPad, Android Tablets eller Windows 8 som avses. Det är en väldigt stor skillnad på dessa olika alternativ.
Uppdatering av operativsystem.
Det är ett faktum att appar behöver uppdateras, varken Apple, Google eller Windows kommer sluta att utveckla sina operativsystem och för att apparna skall fungera optimalt behöver de uppdateras. Denna kostnad behöver vara med i priset för åtminstone det första året – annars kan kostnaden för appen skena iväg ordentligt när den måste uppdateras och man ”sitter fast” med en utvecklare som vill ha dubbla priset för just denna version.
Vilken typ av app?
Det är väldigt sällan vi får veta vilken typ av app som efterfrågas, om den skall vara en nativeapp, hybridapp eller en ren webbapp påverkar både priset och funktionen. Detta är svårt att sätta sig in i men väljer man en ren webbapp tappar man möjligheten till distribution via AppStore och att sända Push-meddelanden. Inget är rätt eller fel, men innan man begär ett pris bör man fundera igenom vad appen skall göra och vad man tror är bäst. Det minsta man bör begära är att utvecklaren förklarar varför man valt det ena eller det andra i sitt anbud.
Läs mer om olika appar här: https://appsales.se/appar/
Hur skall innehåll i appen uppdateras?
Även här ser vi sällan kravspecifikationer på hur eller ens att innehåll som nyheter m.m. skall kunna uppdateras i appen utan att gå via utvecklaren. Skall var ändring hanteras av en utvecklare kommer det att bli en dyr historia. Appar som skall ha levande innehåll som kräver manuell uppdatering bör alltid ha ett fungerande CMS (content management system) detta påverkar priset då detta system dels skall utvecklas men även ha drift och underhåll.
Användning och statistik?
Det kan ju vara trevligt att ha lite användarstatistik på appen utöver antalet nerladdningar. Vad man minst vill veta om appen bör framgå i underlaget. Det går oftast att koppla appen till Google Analytics och få verkligt bra statistik.
Tilläggstjänster.
Skall appen använda Facebook eller andra sociala medier, skall den kunna skicka e-post? Detta kräver att appen har en koppling till dessa tjänster och att detta ingår i lösningen. Annars står man med en app som teoretisk kan använda tjänsterna men som kräver att man själv skapar eller köper tjänsten för att det skall fungera.
Leveranstider.
Nej man kan inte leverera en komplicerad native app för tre operativsystem som är helt kundunikt utvecklad och dessutom med tillhörande CMS system, buggtester och innehållsuppdateringar som finns på App Store m.m. om en månad. Naturligtvis beror det helt på vilken app och vad den skall göra men överoptimistiska leveransförväntningar är mer regel än undantag i branschen. Stora projekt tar flera år att genomföra och de pågår konstant. Ha en realistisk syn på leverans och dela hellre upp projektet i delar än försök att göra allt på en gång.
Support.
Vad gäller när appen är levererad? Vad gäller för buggar och för tekniska problem? Hur får man hjälp om man vill ändra något? Detta är naturligtvis merförsäljning för oss i branschen men det är väldigt mycket trevligare när spelreglerna är klara redan från början så att man slipper överraskningar och missnöje när saker ställs på sin spets. För att det kommer behövas det råder det ingen tvekan om.
Med våra generiska system har vi försökt att underlätta ovanstående beslut för våra kunder – det är sällan vi inte kan möta leveranskraven med något av våra system och då är redan j halva jobbet gjort. I de få fall där det krävs unika programmering offererar vi alltid utifrån verkliga förutsättningar och med ovan områden täckta i underlaget. Kanske straffar det sig ibland på kort sikt att vara tydlig då alla kostnader faktiskt kommer med, men det är så vi vill göra affärer med både kunder och leverantörer.