Rammeverk for chat-drevet utvikling — BBL Pivotal
Formålet er å gi teamet alt de trenger for å starte, bygge og lansere apper via vibekoding på en konsistent, sikker og vedlikeholdbar måte.
v0.2 — Oppdatert med Ians input på hosting, branching, sikkerhet, testing og arkitektur (2. april 2026).
0. Velg nivå
Før du starter: Hvilket nivå passer prosjektet ditt?
| 🔵 Prototyp | 🟡 Intern verktøy | 🔴 Produksjon | |
|---|---|---|---|
| Formål | Validere ide, teste konsept | Internt verktøy for team/avdeling | Eksterne brukere, kunder, BBL-er |
| Eksempel | ”Kan vi bygge dette?” | Timeføring, internt dashboard | Kundeportal, El-vannsjekk |
| Tid til testbar app | 30–60 min | 1–2 dager | 1–2 uker |
| Sikkerhet | Ingen krav | RLS på, ingen service_role | Full pakke: RLS + audit + GDPR + SOC 2 |
| Testing | Ingen | Manuell QA-sjekk | Playwright + CI/CD |
| Branching | Main-branch greit | Feature-branches | Gitflow med PR + code review |
| Drift | Ingen | You build it, run it | Du bygger, drifter + overvåker |
| Dokumentasjon | Ingen | README + datamodell | Full: README + SQL + API + roller |
| GDPR | Ingen | Sjekkliste | Personvernerklæring + cookie + samtykke |
Bruk riktig mal:
- 🔵 Prototyp →
maler/prototyp.md - 🟡 Egne →
maler/egne-verktoy.md - 🔴 Produksjon →
maler/produksjon.md
Malene er arbeidsdokumenter — fyll ut, lagre med prosjektnavn, og jobb fra den. Resten av dette dokumentet er referanse for detaljer.
1. Prinsipper
| Prinsipp | Beskrivelse |
|---|---|
| Data First | Tenk gjennom hvilken informasjon appen trenger å huske FØR du prompter. Du trenger ikke tegne databaser — bare beskriv tingene og sammenhengene i forretningsspråk. AI-en oversetter. |
| Plans are the new code | En god prompt er viktigere enn koden den genererer. |
| Portabilitet | Alt skal kunne flyttes ut av Lovable. SQL dokumenteres, miljøvariabler brukes, ingen proprietær avhengighet. |
| Sikkerhet fra dag 1 | RLS, secrets-håndtering, logging, audit trails og GDPR er ikke noe du «legger til etterpå». |
| Compound Engineering | Bruk standardbiblioteker (Shadcn/Radix/Tanstack). Dokumentér alt slik at det kan rekonstrueres. |
| You build it, run it, fix it | Teamet som bygger appen eier også drift, vedlikehold og feilretting. |
2. Teknisk stack
Påkrevet for alle prosjekter
| Lag | Teknologi | Alternativ |
|---|---|---|
| Frontend | React + TypeScript + Vite | — |
| Styling | Tailwind CSS + CVA | — |
| UI-komponenter | Shadcn UI | — |
| Database | Supabase (PostgreSQL) | GCP-basert DB ved sterke joins mot datasjøen |
| Auth | Supabase Auth (felles modul på tvers av apper) | — |
| Versjonskontroll | GitHub (Gitflow med feature-branches og PRs) | — |
| Utviklingsverktøy | Lovable.dev (primær), VS Code (komplekse apper), Claude Code (sekundær) | — |
| Testing | Playwright (E2E + kritiske workflows) | — |
Design tokens (standard)
Primary: indigo-600
Background: slate-50
UI-språk: Norsk (alle nye apper)
Ian: Sørg for at design tokens er på plass slik at AI-en vet hvilke farger, fonter og komponenter som skal brukes. Alle PivoCore-apper skal ha gjenkjennelig branding.
3. Utviklingsflyt (B.L.A.S.T.)
Alle utviklingsoppgaver følger fem faser:
B — Blueprint
- Lag en presis kravspesifikasjon — definer hva appen skal gjøre før du prompter
- Definér hvem brukerne er og hvilke roller de har
- Beskriv hvilken informasjon appen trenger å huske — hvilke “ting”, hvilken info som hører til, og hvordan de henger sammen. AI-en oversetter til teknisk datamodell. (For produksjonsapper: avklar med teknisk ansvarlig.)
- Definér hvilke sider appen trenger og hva hver side gjør
- Dokumentér dette FØRST — ikke prompt uten plan
Ian: Viktig med en presis kravspesifikasjon slik at man ikke bruker unødvendig tid og tokens på å utvikle noe feil.
Data First for ikke-tekniske: Du trenger ikke kunne SQL. Bare tenk på hvilke “ting” appen din jobber med (prosjekter, timer, kunder), hvilken informasjon som hører til hvert ting (navn, dato, status), og hvordan tingene henger sammen (en time tilhører et prosjekt). Det holder. AI-en fikser resten.
L — Link
- Identifiser eksisterende systemer og API-er appen skal kobles til
- Avklar autentisering og dataflyt mellom systemer
- Dokumentér integrasjoner
A — Architect
- Velg arkitektur basert på A.N.T. 3-lags modell:
- Presentasjon: React + TypeScript + Vite
- Logikk: Custom Hooks for data-fetching
- Data: Supabase med RLS (den eneste sannheten)
- Vurder om appen trenger Edge Functions, Realtime, eller File Storage
- Vurder multi-tenant-arkitektur (se seksjon 11)
S — Stylize
- Bruk Shadcn UI-komponenter — ikke bygg fra scratch
- Følg design tokens og PivoCore-branding
- Responsivt design er påkrevet — alle apper skal fungere på mobil
T — Trigger
- Bruk Prompt-biblioteket (se seksjon 13) for å sikre konsistent arkitektonisk grunnlag
- Prompt Lovable med komplett spesifikasjon (se prompt-mal under)
- Iterer via Chat Mode — refiner funksjonalitet
- Kjør QA-sjekk før lansering (se seksjon 6)
4. Prompt-mal
Alle førsteprompter til Lovable skal følge denne strukturen:
Bygg en [type app] for [hvem]. Bruk Supabase som backend.
## Brukere
[Hvem logger inn, hvordan, hvilke roller]
## Språk
Hele UI-et skal være på norsk.
## Sider og funksjonalitet
### 1. [Side 1]
[Beskriv funksjonalitet, felter, interaksjoner]
### 2. [Side 2]
[...]
## Datamodell (Supabase-tabeller)
tabell_1:
- id, felt_1, felt_2, created_at
tabell_2:
- id, tabell_1_id (FK), felt_1
## Design
- Moderne, minimalistisk
- Primærfarge: indigo-600
- Responsivt — må fungere på mobil
- Sidebar-navigasjon med ikoner
- Norsk UI
- PivoCore-branding (design tokens)
## Tekniske krav
- Supabase Auth for innlogging
- Row Level Security (RLS) på alle tabeller
- Alle miljøvariabler som VITE_-prefix
- Shadcn UI-komponenter
- Standardisert error handling (se seksjon 14)
- Logging og audit trails
For komplekse apper: bruk PIVO-ARC (se Prompting.md) som utvidet ramme.
5. Sikkerhetskrav
Minimum før lansering — ingen unntak
| Krav | Sjekk | Hvordan |
|---|---|---|
| RLS på alle tabeller | Supabase → Database → Tables → «RLS enabled» | Hvis mangler: lag policies |
| Ingen service_role i frontend | Søk i koden etter service_role | Kun anon key i frontend |
| Ingen hardkodede nøkler | Søk etter sk_live_, sk_test_, eyJ, lange alfanumeriske strenger | Flytt til miljøvariabler |
| HTTPS | Vercel/Lovable gir dette automatisk | Verifiser at URL bruker https:// |
| Auth-flyt sikker | Test login, logout, session-timeout | Sjekk at utlogget bruker ikke ser data |
| Logging og audit trails | Hvem gjorde hva når — sporbart | Implementer via Supabase triggers eller middleware |
| GDPR-compliance | Lovpålagt for all brukerdata | Se seksjon 7 |
| SOC 2-vurdering | Vurder for enterprise-apper | Systems and Organization Controls |
| Standardisert feilhåndtering | Felles måte å vise feilmeldinger | Se seksjon 14 |
Secrets-håndtering
| Miljø | Hvor | Format |
|---|---|---|
| Lovable (dev) | Settings → Secrets | VITE_[TJENESTE]_[TYPE] |
| Vercel (prod) | Settings → Environment Variables | Samme variabelnavn |
| Supabase | Settings → API | Allerede lagret |
Regel: Aldri i koden. Alltid i miljøvariabler. VITE_-prefix for frontend-variabler.
6. QA-sjekk (før lansering)
Kjør denne sjekklisten før enhver app går i produksjon:
Kritisk (blokkerer lansering)
- RLS aktivert på ALLE tabeller med korrekte policies
- Ingen API-nøkler i kildekoden
- Auth fungerer: login, logout, uautorisert tilgang blokkeres
- Supabase-prosjekt er i EU-region
- Logging og audit trails fungerer
- Automatiserte tester kjører grønt (se seksjon 15)
Viktig
- Feilhåndtering: slå av internett — vises feilmelding, ikke tom side?
- Skjemavalidering: tomt skjema → tydelig feilmelding
- Destruktive handlinger har bekreftelsesdialog
- Loading states: spinner ved datahenting
- Responsivt: fungerer på mobil (375px)
- Standardisert error handling (seksjon 14) implementert
QA-prompt for Lovable
Lim denne inn i Lovable som siste steg:
Gjennomfør en komplett kvalitetssikring av denne appen. Sjekk:
1. Sikkerhet: RLS, API-nøkler, auth-flyt, audit trails
2. Feilhåndtering: nettverksfeil, tomme skjemaer, destruktive handlinger
3. Edge cases: tomme lister, lange tekster, dobbelt-klikk
4. Responsivt: mobil 375px, touch targets 44x44px
5. Ytelse: lazy loading, LIMIT på spørringer
6. Error handling: følger standardisert mønster (seksjon 14)
Fiks alt du finner og rapporter hva som ble endret.
7. GDPR og personvern
Påkrevet for apper med brukerdata
- Personvernerklæring (norsk) — tilgjengelig fra alle sider
- Cookie-banner ved første besøk
- Samtykke-checkbox ved registrering
- Slettefunksjon: bruker skal kunne slette sin konto og data
- Supabase i EU-region
- Audit trails for dataaksess
8. Versjonskontroll og deploy
Branching-strategi (Gitflow)
Branching med pull requests er påkrevet — main-branch alene er ikke tilstrekkelig.
feature/[navn] → develop → main → produksjon
- feature-branches for all ny utvikling
- Pull requests med code review før merge til develop/main
- Sikrer at AI-generert kode ikke overskriver manuelt rettet kode uten at det oppdages
- Lovable syncer til GitHub automatisk — bruk branches for eksperimentering
Ian: Ved bruk av branching og pull requests sikrer man at AI-generert kode ikke overskriver/endrer kode som er rettet eller skrevet av andre uten at dette blir oppdaget.
Code review
All generert kode skal reviewes av erfaren utvikler. Spesiell fokus på:
- Logikk og forretningsregler
- Sikkerhet (auth, RLS, secrets)
- Databasearkitektur (modeller, relasjoner, indekser)
IDE-valg
| Kompleksitet | IDE | Merknad |
|---|---|---|
| Enkel app | Lovable | Fungerer fint som IDE |
| Kompleks app | VS Code | Når Lovable ikke støtter nødvendig funksjonalitet |
Ian: For mer kompliserte apper vil det være naturlig å flytte til egnet IDE (f.eks VS Code) og gjennomføre testløp der samt release til egnet hosting-miljø.
Flytte ut av Lovable
Prosessen innebærer:
- Sett opp lokal dev-container som matcher Lovables runtime (Vite/React/Tailwind)
- Vurder om forretningslogikk skal separeres til egen backend (Microservices/API eller Cloud Run Functions)
- Alternativt: kjør alt som monolitt
⚠️ Advarsel: Du mister «preview»-loopen i Lovable, og det er ikke mulig å gå tilbake på en enkel måte.
Lovable 2.0 Multiplayer
Ikke testet ennå. Bør fungere for team-utvikling forutsatt at teammedlemmene jobber på ulike deler av produktet for å unngå merge-konflikter.
Deploy-alternativer
| Alternativ | Når | Fordel |
|---|---|---|
| Lovable-hosting | Enkle, isolerte apper — prototyping og enkel produksjon | Null oppsett. Servere i Europa. |
| Google Cloud Run | Enterprise-apper og avanserte prosjekter | Full kontroll, WAF, dype logger, overvåking |
| Azure DevOps | Alternativ til GCP for enterprise | Fullverdig CI/CD |
| ❌ Ikke bruk | Strenge regler: apper og data skal kjøres/lagres i Europa | |
| Vercel | Må undersøkes nærmere | Potensiell kandidat |
Ian: Lovable-hosting mangler WAF og dype logger for IT-sikkerhet/overvåking. For enterprise: Google Cloud Run er naturlig siden avdelingen allerede er i GCP-verden.
9. Drift og vedlikehold
Driftsmodell: «You build it, run it and fix it»
Den avdelingen/teamet som bygger appen eier også drift og vedlikehold etter lansering:
- Oppdateringer og feilretting
- Monitorering og logging
- Støttet av sentral plattformressurs
Første uke etter lansering
- Sjekk Supabase dashboard daglig: API Logs for feil
- Verifiser at audit trails fungerer korrekt
- Be 2-3 brukere teste og samle tilbakemeldinger
Månedlig (15 min)
- Supabase Usage — noe over 70%?
- Åpne appen — fungerer alt?
- Test innlogging
- Eksporter viktige tabeller til CSV (backup)
- Sjekk at GitHub-sync er aktiv
- Kjør automatiserte tester
Kvartalsvis (1 time)
- Sjekk utdaterte/sårbare dependencies
- Rydd testdata
- GDPR: Er det data som bør slettes?
- Gjennomgå audit logs
10. Kostnadsrammer
| Tjeneste | Free tier | Når oppgradere | Pris |
|---|---|---|---|
| Lovable | Begrenset | Ved flere enn 1-2 apper | Fra $20/mnd |
| Supabase | 500MB, 50K auth | Reelle brukere + behov for backup | $25/mnd |
| Vercel | 100GB båndbredde | Sjelden nødvendig | $20/mnd |
| GitHub | Ubegrenset public/private repos | — | Gratis |
| Google Cloud Run | Generøst free tier | Ved enterprise-behov | Bruksbasert |
11. Roller, tilganger og multi-tenant (enterprise)
Standard rollemodell
| Rolle | Tilgang | Eksempel |
|---|---|---|
| Admin | Full tilgang, brukeradmin, innstillinger | Prosjekteier |
| Bruker | Lese/skrive egne data | Ansatt, kundeansvarlig |
| Readonly | Kun lesetilgang | Rapportmottaker |
Implementeres via Supabase Auth + custom claims eller en user_roles-tabell med RLS-policies per rolle.
Multi-tenant arkitektur
For apper som betjener flere BBL-er:
| Modell | Fordel | Ulempe | Når |
|---|---|---|---|
| Delt DB med RLS | Skalerbart, kostnadseffektivt | Høyere krav til penetrasjonstesting, feil påvirker alle | Standard for de fleste apper |
| Separat DB per kunde | Sterk dataisolasjon, feil påvirker kun én kunde | Dyrere, mer vedlikehold | Svært sensitive data / regulatoriske krav |
Ved delt database:
- Strengt logisk skille mellom BBL-er — det skal aldri være mulig å se andres data
- Riktig implementert RLS håndterer dette
- Krav til penetrasjonstesting er høyere enn single-tenant
- Alle data i én DB betyr at feil potensielt påvirker alle kunder
Ian: Delt database med RLS er den mest skalerbare og kostnadseffektive metoden, men det er arkitekturmessige avgjørelser som må tas.
Delte komponenter på tvers av apper
| Komponent | Deles? | Merknad |
|---|---|---|
| Designbibliotek / design tokens | ✅ Ja | Felles PivoCore-branding |
| Datahenting fra felles kilder | ✅ Ja | Datasjøen, felles API-er |
| Felles Auth-modul | ✅ Ja, kritisk | Sømløs brukeropplevelse på tvers av tjenester |
| Forretningslogikk | ❌ Nei | Hver app er uavhengig |
12. Onboarding — «Kom i gang»
For nye teammedlemmer som skal vibekode:
- Les dette dokumentet (15 min)
- Opprett Lovable-konto og koble til GitHub
- Sett opp Gitflow — branch-strategi med feature-branches og PRs
- Lag din første test-app med prompt-malen og prompt-biblioteket (30 min)
- Kjør QA-sjekklisten på test-appen
- Få code review av erfaren utvikler
- Start på ditt prosjekt med B.L.A.S.T.-flyten
13. Prompt-bibliotek
Formål: Sikre at alle apper som lages får samme arkitektoniske grunnlag. En «kokebok» som teamet vet fungerer — slipper å prøve og feile.
Prompt-biblioteket skal inneholde:
- Startprompt for nye apper (se seksjon 4)
- Sikkerhetsprompt — RLS, auth, secrets (seksjon 5)
- QA-prompt — kvalitetssikring (seksjon 6)
- Design tokens-prompt — farger, fonter, PivoCore-branding
- Error handling-prompt — standardisert feilhåndtering (seksjon 14)
- Testing-prompt — Playwright-oppsett (seksjon 15)
Biblioteket bygges ut iterativt etter hvert som teamet samler erfaring.
Ian: Vurder å lage et prompt-bibliotek slik at man sikrer at alle appene som lages får samme arkitektoniske grunnlag. Da kan de som vibekoder bruke dette som en kokebok som man vet fungerer.
14. Standardisert feilhåndtering
Alle PivoCore-apper skal bruke en felles måte å håndtere og vise feil:
Prinsipper
- Brukervennlige feilmeldinger på norsk — aldri vis stack traces
- Konsistent visuell stil (toast/banner/modal avhengig av alvorlighetsgrad)
- Alle feil logges til audit trail
- Nettverksfeil gir tydelig melding — ikke tom side
Kategorier
| Type | Bruker ser | Eksempel |
|---|---|---|
| Validering | Inline-melding ved feltet | «Ugyldig e-postadresse» |
| Nettverksfeil | Toast / banner | «Kunne ikke nå serveren. Prøv igjen.» |
| Autentisering | Redirect til login | Session utløpt |
| Uventet feil | Generisk melding + feilkode | «Noe gikk galt (ERR-500). Kontakt support.» |
15. Automatisert testing
Automatisert testing av applikasjonens funksjonalitet er påkrevet for alle produksjonsapper.
Formål
Sikre at applikasjonen fungerer som tenkt selv etter at nye endringer er introdusert.
Verktøy: Playwright
| Hva | Beskrivelse |
|---|---|
| Kritiske workflows | Login, CRUD-operasjoner, rollebasert tilgang |
| Regresjonstester | Kjøres automatisk ved PR / deploy |
| E2E-tester | Brukerreiser fra start til slutt |
Minimumskrav
- Playwright-prosjekt satt opp i repo
- Tester for alle kritiske brukerreiser
- Tester kjører i CI/CD-pipeline (GitHub Actions)
- Tester kjører grønt før merge til main
QA-prompt for testing
Sett opp Playwright for denne appen. Lag tester for:
1. Login-flyt (gyldig og ugyldig innlogging)
2. Hovedbrukerreise: [beskriv]
3. Rollebasert tilgang: admin vs bruker vs readonly
4. Feilscenarier: nettverksfeil, uautorisert tilgang
Testene skal kjøre i CI via GitHub Actions.
Ian: Få på plass automatisert testing ut fra kravspesifikasjon slik at man er relativt sikker på at applikasjonen fungerer som tenkt selv etter at nye endringer er introdusert. Playwright-tester på kritiske workflows.
16. Avansert prompting — PIVO-ARC
Prompting er å styre et resonnerende system, ikke å gi kommandoer. Du designer kontekst, ikke bare spørsmål.
PIVO-ARC rammeverket
For komplekse oppgaver som krever mer enn prompt-malen (§4):
| Bokstav | Element | Eksempel |
|---|---|---|
| P | Plattformrolle | ”Du er en senior plattform- og produktarkitekt for PivoCore…” |
| I | Intensjon (forretningsmål) | “Modulen skal støtte digitalisering og effektiv drift…” |
| V | Variabilitet | ”Løsningen må støtte: multi-tenant, konfigurasjon fremfor kode, bransjemaler” |
| O | Operasjonalisering | ”Beskriv løsningen slik at den kan implementeres direkte i Lovable…” |
| A | Arkitektur | ”Beskriv: modulens plass i PivoCore, avhengigheter, datadeling” |
| R | Relevante leveranser | Alltid følge standard leveranseformat (se under) |
| C | Constraints | ”Ikke introduser: kundespesifikk kode, logikk som bryter multi-tenant…” |
Master Prompt
Du er en senior plattform- og produktarkitekt med ansvar for PivoCore.
Kontekst:
PivoCore er en multi-tenant SaaS-plattform bygget på low-code (Lovable).
Plattformen leverer moduler innen AI, data, automatisering og digitale produktflater.
Løsninger bygges gjennom konfigurasjon, ikke kundespesifikk kode.
Mål:
Definer en modul eller funksjon som kan inngå i PivoCore som gjenbrukbar kapabilitet.
Krav til tenkemåte:
- Tenk plattform før funksjon
- Skill tydelig mellom fast kjerne og konfigurerbare elementer
- Prioriter enkelhet, skalerbarhet og gjenbruk
Lever:
1. Formål og forretningsverdi
2. Modulbeskrivelse (hva er kjerne vs hva er konfigurerbart)
3. Datamodell (felter, typer, tenant-skilte data)
4. Brukerflyt (interne brukere og sluttbrukere)
5. Avhengigheter til andre PivoCore-moduler
6. Risikoer, begrensninger og forbedringsforslag
Avgrensninger:
- Ikke foreslå kundespesifikk kode
- Ikke overdesign
- Alt skal kunne bygges i Lovable
Iterasjons-flyt
Verdensklasse-prompting skjer sjelden i én prompt:
| Runde | Beskrivelse |
|---|---|
| 1. Utforskning | ”List mulige vinkler / rammeverk” |
| 2. Valg | ”Velg beste tilnærming gitt kontekst” |
| 3. Fordypning | ”Gå dypt i punkt 2 og 4” |
| 4. Kvalitetssikring | ”Hva er svakt / mangler?“ |
| 5. Forenkling | ”Omskriv for ledelse / sluttbruker” |
Standard leveranseformat
Hver modul eller funksjon beskrives med:
- Hva er dette? (én setning)
- Hvem bruker det?
- Hvilket problem løser det?
- Hva er fast kjerne?
- Hva kan konfigureres?
- Hvordan ser en typisk brukerflyt ut?
- Hvordan skalerer dette til 100+ kunder?
Avsluttende kvalitetssjekk
Bruk én av disse etter hver prompt-økt:
| Sjekk | Spørsmål |
|---|---|
| Plattformreview | ”Hvor bryter dette med PivoCore-prinsippene?” |
| Forenklingsrunde | ”Hvordan kan dette løses med færre valg?” |
| Skaleringscheck | ”Hva skjer når 200 kunder bruker dette samtidig?” |
Versjon 0.2 — Oppdatert med Ians input. Sist oppdatert: 2026-04-10. Kilder: PivoCore Arkitekturprinsipper, B.L.A.S.T.-protokollen, PIVO-ARC, intern erfaring, Ian Valle.