Vanlige spørsmål
Det folk vil vite før de kontakter oss.
Vi har samlet de spørsmålene vi får oftest om apputvikling, systemutvikling, pris, prosess og hva som skiller en god utviklingspartner fra en dårlig. Ingen hype, bare ærlige svar.
Apputvikling.
Spørsmål om mobilapp-prosjekter, kostnad, teknologi, App Store, vedlikehold.
Hva koster det å lage en app?
Prisen varierer med kompleksitet. Enkle interne verktøy er rimeligere, mens apper med integrasjoner (BankID, ID-porten, ERP), offline-modus og dashboard koster mer. Komplekse apper med real-time, push, og kompliserte rolle-/tilgangsmodeller ligger høyest. Vi gir ofte fastpris, i større prosjekter gjerne etter et forprosjekt der vi setter scope sammen, slik at du vet hva sluttsummen blir før vi starter.
Hvor lang tid tar det å utvikle en app?
Tiden varierer med omfang, fra forprosjekt og design, via utvikling, til test, godkjenning og publisering i App Store og Google Play. Vi leverer i sprinter så du ser fremgang underveis og kan justere prioriteringer.
Bør jeg bygge native app eller PWA?
Trenger du native maskinvare-integrasjon (avansert kamera, BankID-app, NFC, bakgrunnsoppdatering) eller App Store-synlighet, bygg native. Trenger du å distribuere internt i en bedrift uten App Store-friksjon, vil oppdatere ofte, eller har et begrenset budsjett, er PWA ofte riktig valg og gir mye av native-opplevelsen til en lavere kostnad. Vi diskuterer dette på første møte basert på hva appen skal levere.
Bygger dere i React Native eller native Swift/Kotlin?
Vi bruker React Native med Expo for de fleste apper vi leverer. Det gir native følelse, deler kode mellom iOS og Android, og reduserer både utviklingstid og vedlikeholdskost. For apper som krever tung 3D-grafikk, spesiell maskinvare eller dyp OS-integrasjon bygger vi native i Swift eller Kotlin. Vi har erfaring med begge.
Tar dere ansvar for App Store og Google Play-publisering?
Ja. Vi setter opp Apple Developer Program og Google Play Console hvis dere ikke har det, håndterer sertifikater og provisioning, sender inn til review, svarer på spørsmål fra Apple og Google, og holder appen oppdatert ved policy-endringer. Dere får alltid eierskap på kontoene.
Systemutvikling.
Skreddersydde interne systemer, fagverktøy, CRM/ERP og integrasjoner.
Hva er forskjellen mellom standard CRM og et skreddersydd system?
Et standard CRM dekker generiske prosesser raskt og rimelig, men du må tilpasse virksomheten din til verktøyet. Et skreddersydd system følger DIN prosess, integrerer sømløst med fagsystemene dine, og kan automatisere unike arbeidsflyter. Det lønner seg når dere har mange brukere, arbeidsflyt som standard verktøy ikke matcher, eller integrasjonskrav som blir kompliserte i SaaS-løsninger.
Kan dere integrere mot fagsystemene vi allerede har?
Ja. Vi har erfaring med integrasjoner mot eksisterende fagsystemer, ERP og CRM, samt offentlige tjenester som Altinn, ID-porten og BankID. Bruker dere et bestemt system, ta en prat med oss, så vurderer vi hva som er mulig og hvordan vi best kobler oss på.
Hvor lenge tar det å bygge et internt system?
Tiden varierer med omfang. Et MVP av et fagsystem med et avgrenset sett funksjoner, rolle-tilgang og noen integrasjoner går raskere enn et fullverdig saksbehandlingssystem for en større virksomhet. Vi leverer i sprinter slik at deler tas i bruk underveis, du venter ikke til alt er ferdig på første gevinst.
Hva med sikkerhet, GDPR og personvern?
Personvern og sikkerhet bygges inn fra start. Vi krypterer data i hvile og under transport, har audit-logger på sensitiv data, og tilpasser sikkerhetsnivået til behovet i det enkelte prosjektet. Drift skjer på norsk eller EU/EØS-basert infrastruktur. Vi tar sikkerhet på alvor og tester kritiske systemer før produksjonssetting.
Hva skjer hvis STUDIO X ikke lenger finnes om 5 år?
I de aller fleste prosjekter bygger vi custom, og da eier dere hele kildekoden, databasene og infrastrukturen. Eierskapet avklarer vi alltid før vi signerer en avtale, så det er tydelig fra start. Noen løsninger bygger vi på en felles plattform eller på komponenter vi har laget tidligere (for eksempel vår App Studio-plattform), og da kan modellen være litt annerledes, det sier vi fra om på forhånd. Hvor viktig eierskapet er varierer også: for en startup er det ofte avgjørende å eie koden selv, mens det for en kommune eller organisasjon gjerne handler mer om trygg drift, stabilitet og en leverandør de stoler på over tid. Uansett bygger vi med åpne, dokumenterte teknologier (TypeScript, Postgres, Next.js, React) og legger til rette for en ryddig overlevering, så ingen er låst inne mot sin vilje.
Pris, prosess og kontrakter.
Hvordan vi jobber kommersielt, fastpris, forprosjekt, vedlikehold, betalingsmodeller.
Tilbyr dere fastpris?
Ofte, men ikke alltid, det kommer an på omfang og type prosjekt. Når scopet er tydelig nok, mener vi fastpris er den ærligste modellen for kunder som trenger forutsigbarhet. Vi går først gjennom et forprosjekt der vi setter scope, identifiserer risikoområder, og avtaler hva som er innenfor og utenfor. Deretter gir vi gjerne fastpris på utviklingen, med endringer underveis som klart definerte tilleggsbestillinger. For mer åpne eller utforskende prosjekter passer det bedre å jobbe på løpende timer med tett dialog.
Hva er forskjellen på fastpris og timepris?
Fastpris gir deg forutsigbarhet, du vet hva sluttsummen blir før vi starter. Timepris gir maksimal fleksibilitet, men kan eskalere. Vi anbefaler fastpris for definerte leveranser (MVP, ny app, system) og timepris for løpende videreutvikling og drift etter lansering. De fleste kundene våre starter på fastpris og går over til en månedlig vedlikeholdsavtale når produktet er i bruk.
Krever dere lange bindingsavtaler?
Vi legger vekt på trygghet, stabilitet og sikkerhet over tid. På de fleste prosjekter avtaler vi derfor en bindingstid på 12 måneder med tre måneders oppsigelse for drift og videreutvikling, slik at begge parter har forutsigbarhet. Vilkårene avtaler vi alltid før signering, så de er tydelige fra start. Målet er at du blir værende fordi vi leverer verdi, ikke fordi en kontrakt holder deg igjen.
Hva er et forprosjekt og hvorfor trenger jeg det?
Et forprosjekt er betalt arbeid der vi kartlegger brukere og prosesser, lager wireframes/prototype, identifiserer integrasjoner, vurderer risiko, og setter realistisk scope. Resultatet er en fastpris du kan stole på, et tydelig scope-dokument, og en designprototype du kan vise internt. Om dere trenger et forprosjekt avhenger av omfang: for enklere web-, system- eller PWA-prosjekter går vi ofte rett på spesifisering og workshop etter signert avtale, mens forprosjektet blir stadig viktigere jo større og mer komplekst prosjektet er. For de større prosjektene er det det beste forsikringsbeviset mot at noe havarerer underveis.
Hvordan håndterer dere endringer underveis?
Behov kan endre seg underveis i et prosjekt, og det er helt naturlig. Vi håndterer det ved å logge ønskene, vurdere dem mot eksisterende scope, og gi en kort skriftlig tilleggsbestilling med pris og tidsplan før vi gjør jobben. Du beholder kontrollen, ingenting blir gjort uten din godkjenning, og vi forsøker alltid å unngå overraskelser på fakturaen.
AI, LLM og automatisering.
Claude, GPT, RAG, chatbots, automatisering, hva som fungerer for B2B.
Hva er forskjellen på en chatbot og en RAG-løsning?
En enkel chatbot svarer basert på generell kunnskap i modellen, den hallusinerer ofte om interne forhold. En RAG-løsning (Retrieval-Augmented Generation) henter relevante dokumenter fra DIN kunnskapsbase før den svarer, så svarene er forankret i deres interne data. For B2B-bruk anbefaler vi nesten alltid RAG, det gir kontroll, sporbarhet og dramatisk lavere risiko for feil informasjon.
Kan vi bruke våre interne dokumenter i en LLM uten å gi dem til OpenAI?
Ja. De store leverandørene tilbyr enterprise-avtaler der data ikke brukes til trening og lagres i EU. Alternativt kan vi kjøre open-source modeller i norsk eller EU/EØS-basert drift der ingen data forlater området. Vi designer arkitekturen basert på følsomhets-nivået på dataene deres.
Hvilken AI-modell anbefaler dere, Claude, GPT eller noe annet?
For norsk B2B-bruk anbefaler vi Claude (Anthropic) for kompleks resonering, lange dokumenter og kvalitet på norsk språk. GPT (OpenAI) for høyt volum og bredt utviklerøkosystem. Gemini for Google-stack-integrasjon. Mistral eller Llama hvis dere må kjøre lokalt. Vi velger basert på oppgavens art, ikke hype, og vi designer slik at modell kan byttes ut senere.
Hvor mye sparer vi på å automatisere med AI?
Det avhenger helt av oppgaven. For oppgaver som rapportgenerering, leverandørsjekk og deler av saksbehandling kan AI-assistanse kutte tidsbruken betydelig. Som tommelfingerregel: hvis en oppgave involverer å lese og syntetisere tekst, kan en god del av arbeidet automatiseres med riktig oppsett. Vi vurderer det konkrete potensialet sammen med dere.
Velge utviklingspartner.
Hva du bør spørre etter når du velger noen til å bygge for dere.
Hvorfor velge STUDIO X fremfor et stort konsulenthus?
Hos STUDIO X jobber de samme folkene med deg fra første møte til levering. Du blir kjent med teamet tidlig, og det er erfarne folk som tar reelt eierskap til produktet ditt. Tryggheten ligger i hvem vi er og i kunnskapen og erfaringen vi har bygd opp gjennom mange år. Vi har lavere overhead enn de store, og en tett, personlig dialog hele veien. Trenger du et stort konsulentapparat på en gang, passer et stort hus bedre. Vil du ha et mindre, erfarent team som følger deg over tid, er vi et godt valg.
Har dere erfaring med offentlig sektor og helsefeltet?
Ja. Vi bygger løsninger for offentlig sektor og helsefeltet, der kravene til personvern, universell utforming og kvalitet er høye. Blant annet ble STUDIO X valgt av Oslo kommune ved Velferdsetaten, etter en offentlig anbudskonkurranse, til å utvikle en selvhjelpsapp innen rusfeltet. Vi er vant til krav som WCAG og GDPR, integrasjoner mot offentlige tjenester som Altinn, ID-porten og BankID, og til å jobbe tett med fagmiljøer som eier innholdet og retningen mens vi står for den tekniske løsningen.
Hvilke spørsmål bør jeg stille en utviklingspartner før jeg signerer?
Spør om: Hvem konkret jobber på prosjektet, og hva har de levert før? Se på track record og reelle kundeprosjekter, ikke bare ord. Hvem eier kildekoden og kontoene? Hva skjer hvis vi ønsker å avslutte? Hvordan håndterer dere scope-endringer? Hvilke referansekunder kan jeg ringe? Hvordan ser et reelt prosjektestimat ut, kan jeg få se et eksempel? Svar du ikke får tydelig, eller blir vage på, er røde flagg.
Hva bør jeg ha klart før jeg kontakter dere?
Du trenger ikke en kravspesifikasjon. Du trenger: en kort beskrivelse av problemet du vil løse, hvem som er målgruppen, ca tidsramme, og om dere har et budsjett-spenn. Det holder. Resten finner vi ut sammen.
Hvor mange utviklere jobber på et typisk prosjekt?
Et MVP-team er gjerne lite: en designer, et par utviklere og en prosjekteier. Større prosjekter bemannes med flere utviklere og en arkitekt. Vi holder teamene små fordi koordineringskost ellers blir for høy. Trenger prosjektet mer, deler vi i flere parallelle team med klare grensesnitt.
Holder dere til på kontoret eller jobber dere remote?
De fleste av oss jobber på kontoret i Sarpsborg eller Oslo, der teamet møtes flere dager i uken. Kundedialogen varierer mellom fysiske og digitale møter, ut fra hvor vi er i prosessen. Vi reiser gjerne til kunde for oppstart og workshops, mens løpende samarbeid ofte skjer via Slack/Teams og video. Vi jobber med kunder over hele Norge, og har også erfaring med internasjonale kunder.
Spørsmålet ditt ikke besvart?
Send oss en kort beskrivelse av det dere lurer på. Vi svarer personlig, innen kort tid.