Design
Arkitektur, design og pris er samme valg
Arkitekturvalget bestemmer hvilke skjermbilder som er billige å lage, designvalget bestemmer hvor mye som kan gjentas, og prismodellen er løftet om gjentakelsen. Tre møter, ett valg.
Arkitektur, design og pris er samme valg fordi hvert av de tre setter grensen for hva de to andre kan være. Arkitekturen bestemmer hvilke skjermbilder som er billige å lage. Designet bestemmer hvor mye av leveransen som kan gjentas hos neste kunde. Prismodellen er et løfte om nettopp den gjentakelsen. Velger du ett av dem uten de to andre i rommet, har du valgt alle tre likevel.
Beslutningen tas som regel på tre møter, med tre agendaer og delvis ulike folk. Det er der koblingen forsvinner.
Hva betyr det at de tre valgene er ett valg?
At de tre valgene er ett valg betyr at en endring i ett av dem har en pris i de to andre, og at prisen forfaller lenge etter at beslutningen ble tatt. Arkitekturmøtet handler om drift og skalering. Designmøtet handler om hva brukeren ser. Prismøtet handler om marginen. Alle tre svarer på det samme spørsmålet: hvor mye av dette skal være likt neste gang?
Et selskap som svarer «mye» i arkitekturmøtet og «lite» i designmøtet, har solgt en fastpris det ikke finnes dekning for. Feilen dukker ikke opp i noen av de tre møtene. Den dukker opp i det fjerde leveranseprosjektet, når marginen er borte og ingen kan peke på hvilken beslutning som tok den.
Hvordan blir et arkitekturvalg til en prislapp?
Et arkitekturvalg blir til en prislapp gjennom hvor mange ganger arbeidet kan gjenbrukes. Delt infrastruktur og et felles komponentbibliotek gjør neste leveranse billigere enn forrige, og det er den tekniske forutsetningen et abonnement hviler på.
| Arkitekturvalget | Hva designeren kan tegne | Hva selgeren kan love |
|---|---|---|
| Delt plattform, flere kunder på samme kjerne | Skjermbilder settes sammen av ferdige komponenter | Fast månedspris |
| Egen kodebase per kunde | Hvert skjermbilde kan tegnes fritt | Timepris, eller fastpris med risikopåslag |
| Felles designsystem koblet til frontend-koden | Endringer slår gjennom i alle prosjekter samtidig | Vedlikehold kan selges som abonnement |
| Integrasjon bygget per kunde | Grensesnittet kan følge kundens eget system | Hver integrasjon prises for seg |
| API-first fra start | To grensesnitt må tegnes, ett for mennesker og ett for maskiner | Bruk kan prises, ikke bare antall seter |
Den siste raden er den som endrer seg raskest nå. Et produkt som skal brukes av en agent like mye som av et menneske, har to grensesnitt og dermed to designjobber. Prismodellen som passer, er sjelden den som passet da bare mennesker logget inn.
Over 80 prosent av funksjonaliteten i appene du bruker daglig er den samme. Den ser bare litt annerledes ut.
Hva AppCloud-valget bestemte om prisen
AppCloud er Apps AS' egen low-code-plattform for å designe, utvikle og drifte web- og mobilapplikasjoner på delt infrastruktur. Prisen på AppCloud var en fast månedspris som dekket alle tre delene. Den prisen var mulig fordi fire valg allerede var tatt, og alle fire var tekniske eller designmessige valg med direkte konsekvens for hva som kunne selges.
Apps AS standardiserte designet i et felles designsystem i Figma, med komponenter og maler som var brukt før. Definisjonene ble hentet ut gjennom Figmas API og inn i frontend-koden, som var standardisert i Flutter og React. Infrastrukturen var delt mellom prosjektene. Konfigurasjon og oppfølging lå i et eget administrasjonsgrensesnitt, som Apps AS brukte internt og kunden brukte selv.
Ingen av de fire punktene ser ut som en prisbeslutning. Til sammen er de hele prisbeslutningen. En fast månedspris forutsetter at neste prosjekt koster mindre enn forrige, og de fire punktene er måten forutsetningen ble innfridd på.
Hva skjer når kunden ber om ett skjermbilde til?
Et ønske om ett skjermbilde utenfor komponentbiblioteket er en prisendring, og det er verdt å behandle som en prisendring allerede i møtet der ønsket kommer opp. Selve skjermbildet er billig å tegne. Det dyre er at skjermbildet må vedlikeholdes utenfor systemet hver gang systemet endres.
Regelen er at et avvik fra komponentbiblioteket krever at noen sier ja til vedlikeholdskostnaden, ikke bare til tegningen. Er avviket verdt det, gjøres komponenten om til en del av biblioteket og blir tilgjengelig for alle prosjekter. Er avviket ikke verdt det, tegnes skjermbildet med komponentene som allerede finnes.
Den samme mekanismen er beskrevet fra designerens side i Design er der teknologivalget blir billig. Valget mellom native, React Native og Flutter er den tekniske beslutningen med tydeligst utslag på begge de to andre, og den er gjennomgått for seg i Skal jeg velge native, React Native eller Flutter?.
Hva betyr de tre valgene når grensesnittet er en agent?
Når grensesnittet er en agent, er rettighetsmodellen designet, og designet er prismodellen. Hva agenten har lov til å gjøre, er et arkitekturvalg. Hva mennesket må se før det godkjenner, er et designvalg som følger direkte av arkitekturvalget. Om du kan selge utfall i stedet for tilgang, følger av begge.
Godkjenningsflaten skal vise handlingen agenten vil utføre, argumentene den vil utføre handlingen med, og hvilke av dem som ikke kan angres. Et grensesnitt som bare viser et sammendrag av hva agenten mener den skal gjøre, gir ingen reell godkjenning. Mennesket sier ja til et sammendrag og blir ansvarlig for en handling.
Kan handlingen angres, kan du selge utfallet, fordi du kan garantere å rette det. Kan handlingen ikke angres, selger du fortsatt tilgang og en godkjenningsflate, uansett hva som står i tilbudet. Hvordan risikoen flytter seg når programvaren handler på egen hånd, er gjennomgått i Hva endrer seg når programvaren handler på egen hånd. Driftssiden av de samme valgene står i Personalisering er en driftsoppgave, ikke en kampanje.
Tre spørsmål som hører hjemme i samme møte
Still de tre spørsmålene i samme møte, og skriv svarene på samme ark.
De tre spørsmålene
Hva blir likt neste gang? Svaret er grensen for hvor mye av leveransen som kan prises fast.
Hva må tegnes fra bunnen? Svaret er den delen av prisen som må være variabel, uansett hva kunden ber om.
Hva kan ikke angres? Svaret bestemmer hva et menneske må godkjenne, og dermed hva dere kan garantere.
Hvorfor koblingen er dyrest å overse når selskapet eier produktet selv, står i Hva vi lærer av å bygge egne produkter.
Ta prislappen med inn i arkitekturmøtet
Har dere et arkitekturvalg på bordet nå? Skriv ned de tre svarene over for akkurat det valget og send dem til hello@apps.no. Vi svarer med hvilken prismodell de tre svarene peker på, og hvilket av de tre svarene vi ville endret først.
Kilder
Om denne artikkelen. Skrevet av Espen Hareide, medgrunnlegger og partner i Apps. Ankerartikkel for pilaren Design, teknologi og forretning som én beslutning. Opplysningene om AppCloud, inkludert den halverte leveransetiden og sitatet om åtti prosent, er hentet fra Apps AS' egen case-side for AppCloud, lest 23. september 2026. Hvor mange prosjekter som ligger bak den halverte leveransetiden, står ikke på case-siden og er ikke anslått her. AppCloud er ikke lenger i drift, og årsaken er ikke dokumentert. Artikkelen bruker ingen kundetall.
FAQ
- Hvem bør faktisk sitte i det møtet?
- Den som eier arkitekturen, den som eier designsystemet og den som eier marginen. Det er som regel tre personer, og poenget er at de svarer på spørsmålet om hva som skal være likt neste gang samtidig og høyt. Er det ikke praktisk mulig å samle dem, er minimumsvarianten at den samme skriftlige beslutningen går innom alle tre før noen av dem svarer kunden.
- Hva gjør vi hvis prisen allerede er sendt og arkitekturen ikke bærer den?
- Regn ut hva avviket koster per leveranse før dere forhandler, slik at samtalen handler om et tall og ikke om skyld. Deretter er det to reelle valg: bringe leveransen tilbake til det som kan gjenbrukes, eller beholde skreddersømmen og endre prismodellen ved fornyelse. Å beholde begge deler er den dyreste varianten, og den er også den vanligste.
- Gjelder dette også når vi kjøper en ferdig plattform i stedet for å bygge selv?
- Ja, og da er koblingen strammere, fordi leverandøren allerede har tatt arkitekturvalget for dere. Det dere kjøper er en grense for hva designerne kan tegne, og den grensen bestemmer hva dere kan love kundene deres. Det er verdt å lese prislisten til plattformen som en designspesifikasjon, for det er i praksis det den er.
- Hvor mange avvik fra komponentbiblioteket tåler et prosjekt?
- Sett en grense i antall og hold den, i stedet for å vurdere hvert avvik for seg. Tre til fem avvik i et prosjekt er håndterbart om noen har sagt ja til vedlikeholdet av dem. Fordelen med et tall er at det tvinger fram en prioritering, mens en skjønnsmessig vurdering per sak nesten alltid ender med ja.
- Kan vi prise per utfall når vi bruker en modell fra en leverandør vi ikke kontrollerer?
- Dere kan prise per utfall på den delen av arbeidsflyten dere kan rette opp igjen, uavhengig av hvem som leverer modellen. Det avgjørende er ikke hvem som eier modellen, men om handlingen kan angres. Er svaret nei, selger dere en godkjenningsflate og et ansvar, og da bør prisen si det.
