Kontakt oss

ProgramvareSaaS-utvikling

Bygg en SaaS-tjeneste kundene faktisk tar i bruk

Vi finner ut hva som bør bygges først, tester det med ekte brukere og bygger en tjeneste som tåler flere kunder. Dere får tidlig noe å prøve, ikke bare planer.

Hvor står dere?

Dere har en idé eller et behov, men ikke et produkt ennå. Eksemplene viser en tenkt tjeneste, Driftsbok, fra første behov til plattform.Dere har en plattform med kunder og vil gjøre den bedre. Eksemplene viser Driftsbok som en plattform som allerede har kunder.

Illustrativt eksempel
Behov. Vi snakker med dem som skal bruke tjenesten, og finner det ene problemet som bygges først. Ingenting er bygget ennå. Behov. Supporthenvendelser, bruksdata og samtaler med kunder viser hvilken forbedring som gjør mest. Prototype. Én hel arbeidsflyt, klikkbar. Tre forvaltere prøver den før noe bygges ferdig. Prototype. Forbedringen prøves som prototype, eller slås på for noen få kunder først. Første versjon. Første kunde tar den i bruk. Innlogging, roller og drift er på plass fra start. Første versjon. Grensesnittet forbedres i deler, i koden og designet dere allerede har. Plattform. Flere kunder, samme kode. Hver kunde ser bare sitt. Integrasjoner og abonnement kommer når de trengs. Plattform. Her står dere. Når flere kunder kommer til, er det tilgang, drift og utrulling som først må styrkes.
  1. BehovEtt problem, med brukernes ord.
  2. PrototypeÉn hel arbeidsflyt, klikkbar.
  3. Første versjonGod å bruke hver dag.
  4. PlattformÉn kodebase, mange kunder.

Steg 1 av 4 · idéfaseplattform i drift

Start med ett behov, ikke en funksjonslisteFinn ut hvor kundene strever i det dere har

Vi snakker med dem som skal bruke tjenesten, og finner situasjonen der de strever mest i dag. Det blir utgangspunktet for det som bygges først.

Vi ser på supporthenvendelser, bruksdata og samtaler med kunder. Da blir det tydelig hva som bør forbedres først.

en kort beskrivelse av hvem tjenesten er for, hvilket problem den løser, og hva første versjon skal gjøre.

en prioritert forbedringsliste som produkt og utvikling er enige om.

Tre samtaler, ett behovTre kilder, én forbedring

  • Forvalter«Meldingene kommer på SMS, e-post og telefon. Jeg skriver dem inn i et regneark.»
  • Leietaker«Jeg vet aldri om noen har sett meldingen min.»
  • Håndverker«Jeg får adressen, men ikke hva som er galt.»
  • Support«Hvor finner jeg rapporten fra rørleggeren?»
  • BruksdataSakslisten eksporteres til regneark hver uke.
  • Kundesamtale«Styret vil ha en oppsummering hver måned.»

Bygges først

«Som forvalter vil jeg se alle feilmeldinger fra leietakerne på ett sted, så jeg vet hva som haster.»
«Som forvalter vil jeg se hva håndverkeren har gjort, uten å måtte ringe og spørre.»

Lagt til side: fakturering, rapporter til styret, egen app for håndverkere.ny mobilapp, eget dashbord for styret.

Steg 2 av 4 · prototype

Lag den minste arbeidsflyten som er nyttig aleneTest forbedringen før den rulles ut til alle

Før noe bygges ferdig, lager vi en klikkbar versjon av én hel arbeidsflyt, og ser hva ekte brukere gjør, ikke bare hva de sier.

Vi lager forbedringen som prototype, eller slår den på for noen få kunder først. Da vet dere om den hjelper før alle får den.

Vi ser etter
  • Finner forvalteren den nye saken uten hjelp?
  • Kommer de gjennom hele flyten?
  • Vil de bruke dette i stedet for regnearket?
  • Finner forvalteren rapporten i saken?
  • Slutter de å eksportere til regneark?
  • Spør færre kunder support om rapporter?

svar på om ideen holder, før det brukes mye på utvikling.

et grunnlag for å rulle ut forbedringen til alle, eller justere den først.

Prototype · ny feilmeldingKlikkbar skisse

Leietakeren beskriver feilen og legger ved et bilde.

Forvalteren ser saken med en gang og setter hastegrad.

Håndverkeren får adresse, beskrivelse og bilde.

Leietakeren får beskjed om at feilen er rettet.

Prototype · rapport i sakenKlikkbar skisse

Håndverkeren åpner saken i sin egen visning.

Håndverkeren skriver hva som er gjort og legger ved bilder.

Rapporten ligger rett i saken hos forvalteren.

Saken kommer med i månedsrapporten til styret.

Steg 3 av 4 · første versjonny sakside

Når flyten virker, gjør vi den god å bruke hver dagForbedre grensesnittet uten å starte på nytt

Tydelige statuser, raske handlinger og et uttrykk som passer merkevaren. Alt bygges i et designsystem, så nye skjermbilder blir like gode som de første.

Vi jobber i kodebasen og designet dere har, rydder der det gir mest, og bytter ut gamle skjermbilder gradvis, ikke alt på én gang.

en første versjon brukerne kan ta i bruk, og et designsystem å bygge videre på.

et bedre grensesnitt, levert i deler, uten et stort omskrivingsprosjekt.

Driftsbok · sakerIllustrativt eksempel

ÅpneDenne ukenAlle

Lekkasje under vask

Storgata 12, leil. 3B · Meldt av leietaker i dag 07:42

Storgata 12, leil. 3B · Utført av Rør & Varme AS i går

ForslagForslag til tekst i styrerapportenAI

Rørlegger · Bør ordnes i dagLekkasje i 3B er utbedret. Ingen følgeskader. Basert på beskrivelsen og bildet. Forvalteren bekrefter før noe sendes.Laget fra håndverkerens rapport. Forvalteren godkjenner teksten.

Tildel håndverkerSvar leietaker

Lukk sakenDel med styret

Samme skjermbilde som i prototypen: riktig innhold, ingen form ennå. Tydelige statuser, én handling per rad, og et AI-forslag forvalteren bekrefter. Bygget i et designsystem.

Hvorfor AI her: meldingene kommer inn som fritekst og bilder. Et forslag til fagområde og hastegrad gjør at forvalteren slipper å lese alt før hun kan prioritere. Uten forslaget fungerer tjenesten like godt, bare med litt mer lesing.

Hvorfor AI her: håndverkerne skriver rapportene med egne ord. Et forslag til en kort oppsummering gjør månedsrapporten raskere å lage. Resten av forbedringen trenger ikke AI.

Steg 4 av 4 · plattform

Ta de dyre valgene tidlig, bygg resten når det trengsFinn det som begrenser plattformen før kundene merker det

Noen valg er vanskelige å endre senere, som hvordan kundenes data holdes adskilt. Dem tar vi før første kunde.

Når flere kunder kommer til, er det ofte tilgang, drift eller utrulling som setter grensen. Vi ser på hva som bør styrkes først.

  1. Bestem nåSe på først

  2. Før lanseringVurder

    1. Når det trengsStyrk ved behov

      Kundene holdes adskilt. Hvert forvaltningsfirma ser bare sine eiendommer, saker og leietakere. Løsningen påvirker alt som bygges etterpå.To firmaer bruker samme tjeneste, men ser aldri hverandres data. Roller og innlogging. Ulike brukere skal se og gjøre ulike ting. Større kunder vil ofte logge inn med bedriftskontoen sin.Forvalter, håndverker, leietaker og styreleder får hver sin visning. Integrasjoner. Tjenesten må snakke med systemene kundene bruker, gjennom et API i stedet for eksport og import.Saker kobles til regnskapet, og varsler går ut på SMS og e-post. Drift og overvåking. Dere må vite når noe er tregt eller feiler, før kundene sier fra. Data sikkerhetskopieres, og sikkerheten følges opp.Utviklerne får varsel hvis SMS-varslene slutter å gå ut. Trygg utrulling. Nye versjoner rulles ut i små steg, uten nedetid og med mulighet til å gå tilbake.Den nye rapportfunksjonen slås på for én kunde først. Abonnement og fakturering. Planer, prøveperioder og fakturering må henge sammen med hva kundene faktisk har tilgang til.Styrerapporter følger med i den største planen.

      Dere får en plan for hva som må være på plass før lansering, og hva som kan vente.

      Dere får en vurdering av plattformen og en rekkefølge for hva som bør styrkes.

      Med dere fra produktidé til videre forbedring

      Vi kan ta hele veien, eller gå inn der dere trenger det mest. Har dere egne utviklere, jobber vi sammen med dem.

      1. ProduktidéStarter ofte her

        Samtaler med brukere, avgrensning av første versjon og en plan for hva som skal testes.

        Kunnskap om markedet, kundene og hva dere vil oppnå.

      2. Design

        Brukerflyter, klikkbare prototyper, brukertester og et designsystem.

        Tilgang til brukere og raske tilbakemeldinger.

      3. UtviklingStarter ofte her

        Arkitektur, frontend, backend, integrasjoner og drift, i korte runder.

        En produkteier som tar beslutninger underveis.

      4. Videre forbedring

        Vi følger med på bruken, retter feil og prioriterer neste forbedring sammen med dere.

        Prioriteringer og tilbakemeldinger fra kundene.

      Det vi ofte får spørsmål om

      Hvor stor bør første versjon være?

      Så liten at den kan lages og testes raskt, men stor nok til at én gruppe brukere får løst ett reelt problem fra start til slutt.

      Hva om vi ikke vet om ideen holder?

      Da er det nettopp det vi starter med. Samtaler og en klikkbar prototype gir svar før det brukes mye tid og penger på utvikling.

      Kan dere jobbe videre på en plattform andre har laget?

      Ja. Vi starter med en gjennomgang av kodebasen og arkitekturen, og foreslår hva som bør beholdes, forbedres eller byttes ut.

      Må produktet ha AI?

      Nei. Vi foreslår AI der det gjør noe enklere for brukeren, for eksempel å sortere fritekst eller oppsummere. Ellers lar vi det være.

      Hva koster det?

      Det avhenger av hva som skal bygges. Etter en første samtale foreslår vi en avgrenset start med estimat.

      Les videre

      Hvilket behov skal produktet løse først?Hva bør plattformen bli bedre på først?

      Fortell om ideen og hvem den er for. Vi stiller noen oppfølgingsspørsmål og foreslår et første steg.

      Fortell om plattformen og kundene. Vi stiller noen oppfølgingsspørsmål og foreslår hvor det lønner seg å begynne.

      Bare et kort spørsmål? Still et spørsmål

      Les som Markdown (for AI-agenter)