Øker: booking og betaling
Kalender, kapasitet, betalingsflyt og kvitteringer er egne prosjekter i prosjektet.
Vi oppgir ingen fastpris på nettsider, fordi en brosjyreside og en nettjeneste med booking, betaling og integrasjoner ikke er samme produkt. Funksjonalitet, innholdsmengde, systemer siden må snakke med, og hva som skal driftes etter lansering - det er disse svarene som avgjør omfanget. Denne guiden forklarer hver prisdriver, hva som typisk øker og senker omfanget, hvilke spørsmål du bør stille leverandøren, og hva vi trenger fra deg for å gi en konkret vurdering. Les den før du ber om tilbud, så vet du hva du skal se etter i svarene du får.
Sist oppdatert: 26. september 2026
Start med jobben, ikke med designet. Skal siden informere, selge, ta imot bookinger, behandle betaling, vise Min side-innhold eller følge opp kunder automatisk? Hver jobb betyr funksjonalitet som må bygges, testes og driftes: skjema med validering og varsling, kalender med kapasitet og avbestilling, betalingsflyt med kvittering og refusjon, innlogging med glemt-passord og tilgangsroller. List funksjonene konkret før du ber om pris, og marker hva som må være med ved lansering og hva som kan vente. En side som informerer er noe annet enn en side som selger - og prisen følger jobben, ikke antall sider.
De fleste nettsideprosjekter stopper ikke på teknikk, men på innhold: tekst som ikke er skrevet, bilder som ikke finnes, og menystruktur ingen har bestemt. Hver side trenger overskrift, brødtekst, bilder og kall til handling - ganget med antall sider og språk. Avklar tidlig hvem som gjør hva: skriver dere selv ut fra en mal, eller skal leverandøren skrive, hvem skaffer foto, og hvem godkjenner? Ferdig innhold ved prosjektstart er den billigste måten å holde prisen nede på. Motsatt er uferdig innhold den vanligste grunnen til at lansering sklir - og forsinkelser koster, fordi teamet må holde av tid som ikke kan brukes andre steder.
Med en gang siden må snakke med andre systemer, vokser omfanget: CRM for henvendelser, regnskap for fakturering, bookingsystem for kapasitet, fagsystem for data, nyhetsbrev for samtykker. Hver kobling krever tilgang, testing og feilhåndtering - hva skjer når CRM-et er nede, eller når en betaling feiler halvveis? Moderne API-er med dokumentasjon er rimelige å koble til; eldre systemer uten API kan kreve manuelle rutiner eller spesialtilpasning. List systemene ærlig, og si hvilke koblinger som er kritiske ved lansering og hvilke som kan vente. Mange prosjekter blir billigere av å starte manuelt på ett område - for eksempel eksport av henvendelser på e-post - og automatisere først når volumet forsvarer det.
Hvert ekstra språk er ikke bare oversettelse, det er flere sider å vedlikeholde, flere menyer å holde i synk, og flere versjoner å teste. Maskinoversettelse med menneskelig korrektur er noe annet enn profesjonell transkreasjon av alt innhold - avklar ambisjonsnivået før pris. Samme logikk gjelder brukergrupper: en åpen informasjonsside er én jobb, mens en side med både åpne sider, innlogget kundeportal og ansattvisning fort er tre jobber med ulike tilgangsregler. Start med språket og gruppen som betyr mest for forretningen. Dere kan alltids legge til flere språk og roller etter at kjernen virker og måles.
Design prises etter hvor unikt det må være. En velprøvd mal med deres logo, farger og bilder er rimeligst og ofte helt riktig for en bedriftsside. Tilpasset design på standard byggesteiner gir mer egenart uten å finne opp hjulet på nytt. Full skreddersøm - unike maler per sidetype, animasjoner, illustrasjoner og interaktive elementer - koster mest, fordi alt tegnes og bygges fra bunnen. Spør leverandøren hvilken av de tre nivåene tilbudet ligger på, og hva som konkret er inkludert: antall designutkast, revisjonsrunder og hva som skjer hvis dere ombestemmer dere. Husk at design også er vedlikehold: unike løsninger må testes på nytt ved hver oppdatering.
Lansering er starten, ikke slutten. Hosting, domener, sertifikater, sikkerhetsoppdateringer, sikkerhetskopier, oppetidsovervåking og små endringer koster hver måned - enten som fast avtale eller som løpende timer. Avklar hvem som eier hva: domenet, innholdet, designet, koden og dataene om besøkende. Sørg for administrator tilgang til alt som er deres, og en skriftlig avtale om hva som skjer hvis samarbeidet avsluttes: får dere med dere alt, og i hvilket format? Spør også hvem som retter feil etter lansering, og hvor raskt. En billig side med dyrt, uavklart driftsopplegg er sjelden billig i lengden.
Nettsideprosjekter vokser nesten alltid underveis: noen vil ha chat, noen vil ha nyhetsslider, noen vil ha enda en språkversjon. Hver idé kan være god, men uten spilleregler spiser de budsjettet. Avtal før start hva som er fast scope, hvordan endringsønsker meldes og prises, og hvem som bestemmer om noe tas inn nå eller parkeres til fase to. Be leverandøren si fra tidlig når dere nærmer dere rammen, med forslag til hva som kan kuttes eller forenkles. Vær skeptisk til tilbud uten endringsrutine: de ender enten med krangel om tilleggsfakturaer, eller med at leverandøren svelger kostnaden og mister motivasjonen. Ingen av delene gir en god side.
Be om å få se hva som er fast scope og hva som er antakelser. Spør hvem som skriver tekst og skaffer bilder, og hva som skjer hvis innholdet blir forsinket. Be om å få vite hvordan siden måles: statistikk, mål, lastetid og synlighet. Spør hvem som eier domene, design, kode og data, og hva driftsavtalen dekker måned for måned. Be om å få se en side de har bygget som fortsatt driftes godt etter et par år - det sier mer enn en fersk portefølje. Til slutt: spør hvor mye tid deres egne folk må regne med å bruke på innhold, korrektur og godkjenning. En leverandør som ikke trenger noe fra dere, bygger en side for seg selv.
Beskriv hva siden skal gjøre for kundene deres, i prioritert rekkefølge: informere, selge, booke, følge opp. List systemene den må snakke med, og si hvor mye innhold som finnes i dag - ferdig, utkast eller ikke påbegynt. Fortell hvor mange språk dere trenger ved lansering, og hvordan suksess skal måles: henvendelser, salg, bookinger eller synlighet. Send gjerne to-tre sider dere liker, med én setning om hva ved hver dere liker. Med dette kan vi som regel si om behovet er en enkel side eller en nettjeneste, hva vi ville bygget først, og hva neste steg er. Uten dette må vi gjette - og vi priser ikke på gjetting.
Tommelfingerregler for hva som gjør en nettside større eller mindre. Illustrasjon, ikke løfte om pris.
Kalender, kapasitet, betalingsflyt og kvitteringer er egne prosjekter i prosjektet.
Tekst og bilder klare ved start fjerner den vanligste forsinkelsen.
Hvert system krever tilgang, testing og feilhåndtering.
Velprøvde mønstre for skjema og sider holder både pris og risiko nede.
Hvert språk er flere sider å vedlikeholde, teste og holde i synk.
Prioritert funksjonsliste med must og later gjør tilbud sammenlignbare.
Slik skriver du en forespørsel leverandører kan prise.
Les mer →Se Aprex sin tjeneste for nettsider og nettjenester.
Les mer →Vi oppgir heller ingen pris enn en pris vi ikke kan stå for. Denne siden beskriver hva som påvirker prisen, ikke hva din side koster - det finner vi ut sammen etter at vi har sett behovet. Send oss funksjoner, innholdsstatus og systemer, så svarer vi konkret på hva neste steg bør være.
Beskriv hva siden skal gjøre, hvilke systemer den må snakke med, og hva suksess måles i.
Kontakt Aprex →