NO / EN
Fortell hva dere vil bygge →
Tjeneste / Skreddersydd programvare

Programvare bygget rundt arbeidsflyten, ikke omvendt.

Når standardverktøy krever stadige omveier, regneark på siden og manuelle rutiner for å fungere, koster verktøyet mer enn det sparer. Aprex bygger skreddersydd programvare for virksomheter som trenger portaler, dashboards, interne verktøy, feltapper, SaaS-konsepter eller AI-støttede arbeidsflater. Målet er å bygge akkurat nok produkt til å løse problemet godt, og gjøre det mulig å forbedre løsningen etter bruk. Denne siden forklarer når dere bør bygge selv, hvordan Aprex går fra prototype til drift, og når standardverktøy er det riktige valget.

Diskuter første versjon →Typiske løsninger ↓

Sist oppdatert: 26. september 2026

  1. 01

    Når bør dere bygge selv?

    Skreddersydd programvare passer når standardverktøy gir for mye manuell tilpasning, for dårlig datakvalitet, svake integrasjoner eller feil arbeidsflyt. Det kan også passe når virksomheten har en unik prosess som gir konkurransefortrinn hvis den støttes bedre digitalt. Tegnene er ofte tydelige: ansatte opprettholder parallelle regneark fordi systemet ikke viser det de trenger, nye medarbeidere bruker uker på å lære omveier, eller ledelsen mangler tall fordi data ligger spredt. Før Aprex anbefaler å bygge, sjekkes alltid om et standardverktøy med riktig oppsett eller en enklere integrasjon løser problemet rimeligere. Å bygge selv er riktig når arbeidsflyten er kjernen i virksomheten og verktøyet må følge den, ikke omvendt.

  2. 02

    Fra prototype til drift

    Aprex kan starte med en smal prototype som tester brukerflyt, datamodell, integrasjoner og verdi. Når førsteversjonen virker, kan løsningen bygges videre med tilgangsstyring, logging, drift, ytelse, sikkerhet og vedlikehold. Prototypen er bevisst uferdig på alt unntatt kjerneflyten: den skal svare på om brukerne forstår løsningen og om den løser problemet, ikke imponere med funksjoner. Først når det er bekreftet, legges produksjonskravene til: roller og rettigheter, revisjonslogger, sikkerhetskopiering, overvåking, ytelse under last og dokumenterte deployrutiner. Slik unngås den klassiske fellen der alt bygges på en gang og ingenting blir ferdig.

  3. 03

    AI som del av produktet

    AI kan bygges inn der det hjelper brukeren: søk i dokumenter, forslag til tekst, oppsummering, kvalitetskontroll, rapportutkast eller agentbaserte handlinger. AI bør være tydelig avgrenset og koblet til ansvar, ikke lagt inn som pynt. I praksis betyr det at AI-funksjoner får egne grenser: hvilke data de leser, hva de foreslår, hvem som godkjenner og hva som logges. Brukeren skal alltid se om et innhold er AI-forslag eller bekreftet fakta, og veien tilbake til kilden skal være kort. Aprex bygger AI inn i produktflyten der den sparer tid eller reduserer feil, og lar den være ute der regler og gode skjemaer gjør jobben bedre.

  4. 04

    Integrasjoner fra starten

    Skreddersydd programvare bør ikke bli enda et isolert system. Aprex kan koble løsningen til CRM, ERP, skjema, databaser, dokumentlagring, e-post, dashboards og andre verktøy som allerede brukes. Integrasjonene planlegges før datamodellen låses, slik at systemet snakker samme språk som resten av virksomheten fra dag én. Hver kobling får definert retning, frekvens, autoritativ kilde og feilflyt, på samme måte som frittstående integrasjonsprosjekter. Resultatet er at den nye løsningen styrker datagrunnlaget i stedet for å lage enda en øy med egne tall.

  5. 05

    Tre konkrete case som illustrasjon

    Illustrasjon 1: Et håndverksfirma erstatter papirskjema og meldinger med en enkel feltportal der ansatte registrerer timer, materiell og bilder per oppdrag, mens kontoret godkjenner og sender grunnlaget til fakturering. Illustrasjon 2: En medlemsorganisasjon samler søknader, kontingent og arrangementer i ett dashboard i stedet for tre systemer og manuell avstemming. Illustrasjon 3: Et produksjonsteam får et avviks- og vedlikeholdsverktøy der observasjoner fra gulvet blir oppgaver med ansvar, frist og historikk. Eksemplene er illustrasjoner, ikke beskrivelser av kundeoppsett.

  6. 06

    Slik jobber vi, steg for steg

    Steg 1, forståelse: Aprex kartlegger brukere, arbeidsflyt, systemer og smertepunkter sammen med dem som gjør jobben i dag. Leveranse er en problembeskrivelse med tydelig brukercase og målbare tegn på verdi. Steg 2, prototype: En klikkbar eller fungerende prototype tester kjerneflyten med ekte brukere før det bygges for produksjon. Steg 3, førsteversjon: Ett scope bygges ferdig med integrasjoner, tilgangsstyring, logging og dokumentasjon. Steg 4, prøvedrift: Løsningen brukes i avgrenset drift mens feil, ytelse og bruksmønster måles. Steg 5, drift og videreutvikling: Eierskap, overvåking og vedlikehold avtales, og nye behov prioriteres etter målt verdi i stedet for ønskelister.

  7. 07

    Typiske systemer og integrasjonspunkter

    Skreddersydde løsninger lever sjelden alene. Typiske kategorier de kobles mot, er CRM og saksverktøy for kunde- og saksdata, ERP og regnskap for ordre og økonomi, identitets- og påloggingstjenester for sikker tilgang, e-post og SMS for varsler, dokumentlagring for vedlegg, samt eksterne API-er for kart, betaling eller oppslag der behovet finnes. Aprex velger etablerte rammeverk og dokumenterte grensesnitt, slik at løsningen kan vedlikeholdes og utvides uten å være avhengig av én enkelt utvikler eller et obskurt bibliotek.

  8. 08

    Når standardverktøy er bedre

    Skreddersydd passer dårlig når behovet dekkes av et modent standardverktøy med riktig oppsett, når budsjettet ikke tåler vedlikehold over tid, eller når kravene endrer seg så raskt at et egenbygd system blir utdatert før det er ferdig. Det passer også dårlig når virksomheten egentlig trenger å standardisere prosessen sin snarere enn å systemsette unntakene. Aprex sier fra når kartleggingen peker dit, og hjelper heller med valg, oppsett eller integrasjon av standardverktøy. Å la være å bygge er ofte den mest lønnsomme rådgivningen.

  9. 09

    Bevis fra egne produkter

    Aprex drifter produkter i tillegg til kundeprosjekter. TapInn driftes av Aprex og samler innsjekk, sjekklister, HMS, avvik, dokumentasjon og integrasjoner for ansatte i felt. Farled er i pilot, uten besluttet lanseringsdato, og viser hvordan et SaaS-konsept testes: smal salgsflyt først, med tilbudsutkast og oppfølging, før bredere CRM-funksjonalitet vurderes. 24AI og 24Markets er labs-produkter som viser automatisert dataflyt og publisering i produksjonslignende drift. Felles er produktdisiplinen: smalt scope, ekte brukere tidlig og utvidelse basert på målt verdi.

Oversikt

Typiske løsninger

Dette er produktflater der skreddersydd programvare ofte gir mer verdi enn å tvinge arbeidsflyten inn i et standardverktøy.

Interne portaler

Samle oppgaver, data, dokumenter og beslutninger i én arbeidsflate for teamet, med roller og tilgangsstyring.

Dashboards

Vis nøkkeltall, drift, status, avvik og beslutningsgrunnlag fra flere datakilder med synlige kilder.

Feltapper

Støtt ansatte ute med innsjekk, sjekklister, bilder, avvik og dokumentasjon. TapInn driftes av Aprex.

Les mer →

SaaS-konsepter

Bygg første versjon av et produkt, test markedet og forbedre med faktisk bruk. Farled testes nå som pilot.

Les mer →

AI-verktøy

Lag interne copiloter, dokumentflyt eller AI-assistenter som inngår i en større arbeidsflate.

Les mer →

Adminsystemer

Bygg kontrollpaneler for innhold, kunder, produkter, saker, tilbud eller operasjonell drift.

AI-byrå for småbedrift (ressurs)

Slik velger en småbedrift riktig AI-partner.

Les mer →

Slik jobber Aprex

Metoden bak leveransene: kartlegging, prototype, pilot, drift og forbedring.

Les mer →
FAQ

Skreddersydd programvare FAQ

Er skreddersydd programvare dyrere enn standardverktøy?
Ikke alltid. Standardverktøy kan bli dyrt når det krever mye manuelt arbeid, dårlige prosesser eller flere separate systemer. Riktig scope er avgjørende, og noen ganger er riktig svar å ikke bygge i det hele tatt.
Hva koster skreddersydd programvare?
Omfanget styrer arbeidet: antall brukergrupper, flyter, integrasjoner og produksjonskrav som tilgang, logging og drift. En intern portal mot ett system er noe annet enn et kundevendt produkt med mange integrasjoner. Aprex gir ingen fastpris uten å ha sett behovet; send en beskrivelse av brukere, flyt og systemer for en konkret vurdering.
Hvor bør første versjon starte?
Start med én tydelig brukergruppe og én kjerneflyt. Første versjon bør bevise verdi, ikke dekke alle fremtidige ønsker. Prototypen tester om flyten forstås før det bygges for produksjon.
Kan Aprex overta eksisterende kode?
Det kan vurderes etter teknisk gjennomgang. Før videre bygging bør kodekvalitet, sikkerhet, deploy, avhengigheter og datamodell kartlegges. Noen ganger er det rimeligere å bygge nytt rundt en kjerne som beholdes.
Hvordan unngår vi at løsningen blir vanskelig å vedlikeholde?
Hold scope tydelig, bygg med etablerte rammeverk, dokumenter sentrale valg, automatiser deploy og lag enkel vei for feilsøking og videreutvikling. Aprex velger kjedelig, velprøvd teknologi der det er mulig.
Hvem eier koden og dataene?
Virksomheten eier løsningen, koden og dataene etter avtalte vilkår, med dokumentasjon som gjør det mulig å drifte og videreutvikle uten å være låst til én leverandør.
Trenger vi skreddersydd når AI-verktøy finnes ferdig?
Ferdige AI-verktøy dekker generelle behov, men sjelden deres eksakte flyt, data og ansvarslinjer. Skreddersydd lønner seg der AI må kobles til egne systemer med tilgang, logging og godkjenning. Les guiden om AI-agent mot chatbot for å se forskjellen.
Hvordan håndteres sikkerhet?
Tilgangsstyring, dataminimering, logging og sikre deployrutiner er del av leveransen fra første produksjonsversjon. Sensitive data og produksjonsnære integrasjoner avklares før drift. Les mer på sikkerhetssiden.
Tillit

Produktdisiplin

Aprex bør bygge programvare som tåler endring. Det betyr tydelig scope, enkel arkitektur der det er mulig, reell brukerfeedback og ærlig prioritering av hva som må bygges nå og hva som bør vente. Der standardverktøy er bedre, sier Aprex det heller enn å bygge noe virksomheten ikke trenger.

Har dere en arbeidsflyt standardverktøy ikke løser?

Send en kort beskrivelse av brukerne, prosessen, systemene og hva dagens løsning ikke får til.

Diskuter første versjon →