Multi-tenant arkitektur
Én kodebase, isolerte data per byrå og kunde. Vi bygger dette riktig fra start slik at du slipper en kostbar ombygging når du skalerer forbi de første ti kundene.
Regnskapsbransjen er full av manuelle prosesser som kan løses digitalt. Vi bygger SaaS-produktet som lar deg selge løsningen til flere byråer, ikke bare bruke den internt.
De fleste SaaS-ideer i regnskapsbransjen starter med en intern frustrasjon: et regneark som er blitt for stort, en manuell rutine som tar for lang tid, eller et gap mellom systemene byrået allerede bruker. Det er ofte et godt utgangspunkt, fordi det betyr at du kjenner problemet fra innsiden. Utfordringen er å gå fra «dette løser vårt problem» til «dette kan vi selge til hundre andre byråer».
Regnskapsbransjen har noen særtrekk som påvirker hvordan et SaaS-produkt bør bygges. Dataene er sensitive og reguleres av bokføringsloven, kundene forventer integrasjon mot systemer de allerede bruker som Fiken, Tripletex og Visma, og kjøpsbeslutningen tas ofte av noen som er skeptisk til nok et verktøy. Det betyr at teknisk arkitektur og salgsstrategi henger tettere sammen enn i mange andre bransjer.
Vi bygger SaaS for regnskapsbransjen med utgangspunkt i hva som faktisk får et byrå til å bytte verktøy: tidsbesparelse som er synlig fra første uke, trygghet rundt data og en onboarding som ikke krever ukesvis med opplæring. Resten av denne siden går gjennom hvordan vi tenker rundt integrasjoner, datasikkerhet, MVP og skalering når vi bygger denne typen produkt.
Regnskapsbyråer i Norge digitaliserer i høyt tempo, men mange sitter fortsatt med fragmenterte verktøy som ikke snakker sammen. Det skaper rom for produkter som løser ett problem svært godt, fremfor nok en «alt-i-ett»-plattform. Samtidig er bransjen konservativ på kjøp, så produktet må bevise verdi raskt og integrere sømløst med det byrået allerede har.
Byråer bytter sjeldnere hovedsystem (Visma, Tripletex, Fiken), men kjøper gjerne tilleggsverktøy som løser et spesifikt problem — det gjør nisje-SaaS mer levedyktig enn å konkurrere mot hovedsystemene direkte.
Prising per klient eller per transaksjonsvolum fungerer ofte bedre enn flat pris per bruker, fordi det følger byråets egen vekst og forretningsmodell overfor sluttkundene.
Datasikkerhet er ikke bare et teknisk krav, men et salgsargument. Byråer som vurderer verktøyet ditt vil spørre om databehandleravtale, lagringssted og tilgangsstyring før de tester det.
Et produkt som sparer synlig tid på en konkret oppgave — avstemming, purring, rapportering — selger lettere enn et generisk «effektiviseringsverktøy» uten tydelig bruksområde.
Én kodebase, isolerte data per byrå og kunde. Vi bygger dette riktig fra start slik at du slipper en kostbar ombygging når du skalerer forbi de første ti kundene.
Kobling mot Fiken, Tripletex og Visma via API, slik at data flyter automatisk i stedet for å kreve manuell eksport og import hos kunden.
Byrå, sluttkunde og eventuelt regnskapsfører trenger ulike tilganger til samme data. Vi bygger rettighetsstyring som følger hvordan bransjen faktisk er organisert.
Før vi skriver kode, snakker vi med potensielle kunder for å bekrefte at problemet er stort nok og at de faktisk vil betale for en løsning.
Vi lager en versjon som løser kjerneproblemet for én integrasjon og én kundetype, slik at du kan teste betalingsvilje raskt.
Når MVP validerer retningen, bygger vi arkitekturen som skal bære flere kunder samtidig — med isolasjon, logging og tilgangsstyring på plass.
Vi setter opp overvåking, driftsrutiner og en plan for hvilke funksjoner som bygges ut basert på faktisk bruk hos de første kundene.
Mange SaaS-prosjekter i denne bransjen feiler ikke fordi produktet er dårlig bygget, men fordi det er bygget for bredt før noen har betalt for det. Vi anbefaler nesten alltid å starte smalere enn det gründeren først foreslår: én integrasjon, én arbeidsflyt, én tydelig målgruppe. Det gjør det mulig å få betalende kunder raskere, og du lærer hva som faktisk driver kjøpsbeslutningen før du bygger videre.
Kostnadsstrukturen i et SaaS-produkt er annerledes enn i et vanlig kundeprosjekt. Hver ny kunde skal helst koste mindre å drifte enn den forrige, og det krever at arkitekturen er tenkt gjennom fra start — spesielt rundt datamodell, tenant-isolasjon og API-bruk mot tredjepartssystemer som Visma og Tripletex, hvor rate limits og API-endringer kan påvirke drift for alle kunder samtidig hvis det ikke er bygget robust.
Vi tar ofte rollen som teknisk partner videre etter første lansering, fordi et SaaS-produkt sjelden er «ferdig» — det utvikler seg i takt med kundenes tilbakemeldinger og endringer hos regnskapssystemene det integrerer mot. Det gir deg en forutsigbar samarbeidspartner fremfor å måtte bygge opp et internt teknisk team før du vet om produktet har livets rett.
Integrasjon mot Fiken, Tripletex og Visma er ofte kjernen i verdiforslaget, men også der de fleste tekniske overraskelser dukker opp. Fiken har et enklere API som passer godt for mindre byråer og enkeltmannsforetak, mens Tripletex og Visma har mer omfattende API-er med flere krav til autentisering og datamodellering. Vi kartlegger tidlig hvilke systemer målgruppen faktisk bruker, slik at du ikke bruker utviklingstid på en integrasjon få av dine potensielle kunder trenger.
Multi-tenant betyr at flere kunders data lever i samme system, men skal være fullstendig isolert fra hverandre. Dette kan løses på flere nivåer — egen database per tenant, delt database med tenant-id på hver rad, eller en hybrid. Valget påvirker både sikkerhet, driftskostnad og hvor raskt du kan onboarde en ny kunde. For regnskapsdata anbefaler vi som regel en arkitektur med tydelig logisk isolasjon og streng tilgangskontroll, kombinert med logging som gjør det mulig å dokumentere hvem som har hatt tilgang til hva.
Datasikkerhet handler ikke bare om kryptering og tilgangsstyring, men om å kunne svare på konkrete spørsmål fra byråer som vurderer verktøyet: Hvor lagres dataene? Hvem har tilgang internt hos dere? Hvordan håndteres sletting når en kunde avslutter avtalen? Vi bygger inn svar på disse spørsmålene i produktet fra start, fremfor å måtte legge det til i etterkant når en stor kunde krever det i en avtaleprosess.
Når produktet har funnet fotfeste hos de første kundene, endrer skaleringsutfordringen seg fra «virker dette» til «tåler dette last og drift over tid». Det innebærer overvåking av API-kall mot tredjepartssystemer, håndtering av feilsituasjoner når Visma eller Tripletex har nedetid, og en driftsmodell som ikke krever manuell inngripen for hver ny kunde som onboardes. Dette er arbeidet som avgjør om et lovende produkt faktisk kan drives i stor skala.
Ja. Vi anbefaler alltid samtaler med potensielle byråkunder før utvikling starter, slik at du vet at problemet er stort nok til at noen betaler for det.
Det avhenger av hvilke systemer målgruppen din faktisk bruker. Vi hjelper deg kartlegge dette før vi prioriterer utviklingsrekkefølgen.
Ja, det er ofte den beste strategien. En smal MVP med én integrasjon gir raskere validering enn å bygge bredt fra dag én.
Du får markedsvalidering, teknisk arkitektur for multi-tenant, prioritert integrasjonsplan, MVP-utvikling, sikkerhetsgjennomgang og en driftsmodell for videre skalering — slik at produktet er klart for flere kunder uten at det krever full ombygging underveis.
Vi svarer raskt med ærlig vurdering av scope, teknisk retning og realistisk fremdrift.
Gå til kontaktDet avhenger av antall integrasjoner og kompleksitet i multi-tenant-arkitekturen, men en realistisk MVP starter typisk fra 250 000–400 000 NOK. Vi gir konkret estimat etter kartlegging.
Ja, men vi anbefaler å starte med den integrasjonen flest av dine potensielle kunder faktisk bruker, og utvide etter at produktet har bevist verdi.
Ja, dette blir ofte etterspurt tidlig i en salgsprosess mot byråer. Vi bygger inn dokumentasjon og tekniske løsninger for dette allerede i MVP-fasen.
Del kort hva du ønsker å få løst, så gir vi en konkret anbefaling av neste steg.