# HeidiMail.dk — Projektbeskrivelse

## Dokumentets formål

Dette dokument er den samlede projektbeskrivelse for HeidiMail.dk. Det fungerer som den autoritative kilde til produktvision, features, tekniske beslutninger, arkitektur og roadmap. Dokumentet er designet til at kunne bruges som kontekst/input til AI-assistenter og som grundlag for at generere tasks, milestones og user stories.

---

## 1. Produktvision

### 1.1 Hvad er HeidiMail?

HeidiMail er en dansk email-tjeneste med fokus på privatliv, datasuverænitet og integrerede samarbejdsværktøjer. Alle data hostes i Danmark under dansk jurisdiktion og er ikke underlagt den amerikanske CLOUD Act.

HeidiMail kombinerer tre kernefeatures som ingen eksisterende udbyder tilbyder samlet:

1. **Sikker email** — hostet i Danmark med fuld GDPR-compliance
2. **Kontekstuel chat** — integreret chat knyttet til email-tråde
3. **Kollaborativ email-redigering** — flere brugere kan redigere en email-body i realtid

### 1.2 Kerneværditilbud

"Dine data forlader aldrig Danmark."

HeidiMail er ikke bare endnu en email-udbyder. Det er svaret på et konkret problem: danske virksomheder, offentlige institutioner og privatpersoner er afhængige af amerikanske tech-giganter (Gmail, Outlook/Microsoft 365) til deres mest fortrolige kommunikation — og den afhængighed er en sikkerhedsrisiko.

### 1.3 Hvorfor nu?

- Den danske regering har aktivt anbefalet at gøre den offentlige sektor uafhængig af Google og Microsoft (ekspertgruppens anbefalinger, december 2024)
- Digitaliseringsminister Caroline Stage har lanceret pilotprojekter med open source-alternativer
- Færdselsstyrelsen modtog i december 2025 den første Microsoft-fri pc i staten
- København og Aarhus er begyndt at udfase Microsoft-løsninger
- EU vedtog i november 2025 en "Declaration for European Digital Sovereignty"
- CLOUD Act-konflikten med GDPR er uløst — Microsofts franske chef har under ed erklæret at han ikke kan garantere at europæiske data ikke udleveres til USA
- Markedet for sikker email vokser med 12-20% årligt

### 1.4 Navn og domæne

Produktet hedder **HeidiMail** og opererer under domænet **heidimail.dk**. Alle brugere får en @heidimail.dk adresse. Custom domains er en planlagt B2B-upsell i en senere fase.

Navnet er bevidst venligt og tilgængeligt — ligesom Hey.com og Hello Monday har bevist at et uformelt navn kan fungere i professionelle kontekster.

---

## 2. Målgrupper

### 2.1 Primær: Danske virksomheder i regulerede brancher

- **Advokatfirmaer** — tavshedspligt kræver sikker kommunikation, krypteret mail er lovpligtigt for fortrolige data
- **Sundhedssektor** — patientdata er særligt følsomme under GDPR, Datatilsynet kræver kryptering
- **Finanssektoren** — DORA kræver fra 2025 streng kontrol med ICT-leverandører og datasuverænitet
- **Revisorer og rådgivere** — håndterer klienters fortrolige økonomiske data dagligt

### 2.2 Sekundær: Offentlig sektor

Kommuner, regioner og statslige institutioner der er i gang med eller planlægger omstilling væk fra Microsoft. Regeringens ekspertgruppe anbefalede specifikt at tre pilotkommuner støttes økonomisk i at overgå til alternativer.

### 2.3 Tertiær: Privacy-bevidste privatpersoner

Danskere der ønsker et alternativ til Gmail/Outlook. Proton Mails vækst til 100+ mio. konti beviser at segmentet er reelt.

---

## 3. Forretningsmodel

### 3.1 Overordnet model

B2C-first med B2B-upsell. Alle brugere starter med @heidimail.dk. Custom domains tilføjes som premium-feature for virksomheder i en senere fase.

### 3.2 Pricing (foreløbig)

Endelig pricing fastlægges efter markedsvalidering. Referencepriser fra konkurrenter:

- Proton Mail: gratis / €4+ pr. måned
- Tuta Mail: gratis / €3+ pr. måned
- Google Workspace: $6+ pr. bruger/måned
- Microsoft 365: $6+ pr. bruger/måned

### 3.3 Revenue streams (planlagt)

- Per-bruger abonnement (kerne)
- Ekstra storage
- Custom domains (B2B-upsell)
- Premium collaboration-features
- Chat som inkluderet eller add-on afhængigt af tier

---

## 4. Features — Detaljeret beskrivelse

### 4.1 Email (KLAR)

#### Status: Produktionsklar

#### Teknisk fundament
- **Server:** Stalwart Mail Server (Rust-baseret)
- **Protokoller:** JMAP, IMAP, SMTP
- **Sikkerhed:** DKIM, SPF, DMARC
- **Filtrering:** Sieve-baseret filtrering
- **Webclient:** .NET Core, fuldt funktionel

#### Funktionalitet i webclienten
- Læse, skrive og besvare emails
- Labels/mapper til organisering
- Drafts med auto-save
- Standard email-funktionalitet (videresend, CC/BCC, vedhæftninger)

#### Sikkerhed i fase 1
- Data krypteret in transit (TLS)
- Data hostet i Danmark under dansk jurisdiktion
- Ikke underlagt CLOUD Act
- **Totrinsbekræftelse (2FA):** TOTP-baseret via authenticator-apps (Google Authenticator, Authy m.fl.), QR-kode setup, 10 recovery codes, password-bekræftelse på alle sikkerhedshandlinger
- E2E-kryptering at rest er planlagt til fase 3

#### Vigtige noter
- Der er IKKE E2E-kryptering at rest i fase 1. Markedsføringen skal være præcis: "data hostet i Danmark under dansk lovgivning" — ikke "end-to-end krypteret". Troværdighed er afgørende.
- IP/domæne-reputation skal opvarmes gradvist efter launch. De første måneder vil deliverability til Gmail/Outlook være udfordrende.

---

### 4.2 Chat (PLANLAGT — Fase 1)

#### Status: Skal bygges. Prioritet: Høj.

#### Baggrund for featuren
Email er asynkront. Når flere personer samarbejder om en email (f.eks. et svar til en klient), opstår der behov for hurtig koordinering. I dag bruger folk Teams, Slack eller telefon til dette. HeidiMails chat eliminerer det kontekst-skift ved at integrere chat direkte i email-konteksten.

#### Arkitektur
- **Transport:** SignalR (WebSocket med fallback til long polling)
- **Stack:** .NET Core — bygger oven på den eksisterende webclient-stack
- **Autentificering:** Kun HeidiMail-brugere kan deltage i chat. Ingen gæsteadgang.

#### To typer chat

##### 4.2.1 Kontekstuel chat (knyttet til en email)
- **Trigger:** Brugeren har en email åben med flere modtagere (f.eks. 5 personer). Brugeren klikker "Start chat".
- **Handling:** Et chatvindue åbner. De øvrige HeidiMail-modtagere på emailen modtager en notifikation om at chatten er åben.
- **Kontekst:** Chatten er knyttet til den specifikke email-tråd. Alt der diskuteres har implicit kontekst fra emailen.
- **Deltagere:** Alle HeidiMail-brugere der er modtagere på emailen. Ikke-HeidiMail-modtagere (f.eks. @gmail.com) kan IKKE deltage.
- **Persistens:** Chathistorik gemmes og er tilgængelig når emailen åbnes igen.

##### 4.2.2 Ad hoc chat (ikke knyttet til en email)
- **Trigger:** Brugeren opretter en ny chat og inviterer deltagere.
- **Kontekst:** Ingen email-parent. Chatten ejes af initiator.
- **Formål:** Hurtig kommunikation der ikke relaterer sig til en specifik email.

#### Vigtige designbeslutninger
- **Kun HeidiMail-brugere:** Dette simplificerer arkitekturen markant (ingen gæsteadgang, ingen eksterne tokens). Det skaber også et naturligt viralt incitament: "Jeg kan ikke chatte med dig om denne mail — opret en HeidiMail-konto."
- **Chat er også koordineringslag for kollaborativ redigering:** Se afsnit 4.3.

#### Ikke-funktionelle krav
- Realtid (lav latency via WebSocket)
- Pålidelig levering (besked skal nå alle deltagere)
- Reconnection-håndtering (SignalR håndterer dette)
- Notifikationer til brugere der ikke har chatten åben

---

### 4.3 Kollaborativ email-redigering (PLANLAGT — Fase 2)

#### Status: Skal bygges. Prioritet: Medium (efter chat).

#### Baggrund for featuren
I mange professionelle kontekster skrives emails i samarbejde — f.eks. et advokatfirma der formulerer et svar til en modpart, eller en afdeling der skriver en vigtig meddelelse. I dag sker dette via "skriv et udkast, send det rundt, saml kommentarer, skriv nyt udkast." HeidiMail gør dette real-time.

#### Arkitektonisk tilgang: Pragmatisk, ikke Google Docs

Den kollaborative redigering bruger IKKE CRDT (Conflict-free Replicated Data Types) eller OT (Operational Transformation). Disse algoritmer er ekstremt komplekse og designet til scenarier med mange samtidige brugere i store dokumenter.

En email er fundamentalt anderledes:
- Typisk kort (få afsnit)
- Få samarbejdspartnere (2-5 personer)
- Skrives over minutter, ikke timer
- Deltagerne har allerede en chatkanal åben

Derfor bruges en **cursor-broadcasting + menneskelig koordinering** model:

#### Funktionalitet
1. **Cursor/badge-visning:** Alle deltageres cursors og navne-badges vises i realtid i email-bodyen. Broadcastes via SignalR (samme infrastruktur som chat).
2. **Tekst-broadcasting:** Ændringer i teksten broadcastes til alle deltagere i realtid.
3. **Chat som koordinering:** Chatbaren kører i sidebar. Deltagerne koordinerer verbalt: "Jeg tager indledningen, du skriver punkterne."
4. **Konflikthåndtering:** Ingen algoritmisk conflict resolution. Hvis to brugere redigerer i samme område, ser de det øjeblikkeligt via cursor-visningen og koordinerer i chatten. Worst case overskriver den sidste ændring — og de kan rette det med det samme.

#### Hvorfor denne tilgang virker
- Transport-laget (SignalR) eksisterer allerede fra chat-featuren
- 90% af værdien ved fuld collaboration med en brøkdel af kompleksiteten
- Chat-kanalen gør algoritmisk conflict resolution overflødig
- For emails er det en ideel løsning — det er ikke et 200-siders dokument med 50 brugere

#### Mulig fremtidig forbedring
- Afsnitsbaseret soft-locking: Når bruger A redigerer et afsnit, vises en farvet markering for de andre. Ikke en hård lås, men en visuel indikation.

---

### 4.4 End-to-end kryptering at rest (PLANLAGT — Fase 3)

#### Status: Fremtidig feature. Kræver native app først.

#### Baggrund
I fase 1 og 2 er data krypteret in transit (TLS) men ikke at rest. Det betyder at HeidiMail som operatør teknisk set kan læse brugernes mails. Dette er samme model som Gmail og Outlook bruger, men med den fordel at data er under dansk jurisdiktion.

I fase 3 tilføjes valgfri E2E-kryptering at rest, så selv HeidiMail ikke kan læse indholdet.

#### Forudsætning: Native app
E2E-kryptering at rest kræver en native app (desktop + mobil) med lokal storage. Grunde:

- **Søgning:** Server-side søgning er umulig i krypteret indhold. Søgeindeks skal bygges og gemmes lokalt.
- **Browser-storage er upålidelig:** IndexedDB i browsere kan slettes af storage pressure, cache-rydning, eller iOS Safari (som rydder IndexedDB efter 7 dages inaktivitet).
- **Native app kontrollerer storage:** Ingen risiko for at OS'et sletter data.

#### Funktionalitet (fase 3)
- Brugerens mailbox krypteres at rest på serveren med brugerens nøgle
- Dekryptering sker udelukkende i den native app
- Lokal søgeindeksering i appen
- Progressiv indeksering ved første login på ny enhed (download + dekrypter alle mails i baggrunden)
- Valgfrit per bruger — brugere der ikke ønsker E2E kan fortsætte med webclienten

#### Privacy-implikation
- Med E2E at rest kan HeidiMail ved en editionskendelse svare: "Vi kan teknisk ikke læse brugerens mails."
- Uden E2E at rest skal HeidiMail udlevere data efter dansk lov.
- Denne forskel er et stærkt differentierings- og markedsføringsargument.

#### Vigtige tekniske overvejelser
- **Password reset:** Med E2E at rest er password reset problematisk — nyt password = ny nøgle = adgang til gamle mails tabt (medmindre recovery key bruges). Proton løser dette med en recovery phrase.
- **Multi-device:** Nøgler skal synkroniseres sikkert mellem brugerens enheder.
- **Key management:** Nøglepar skal genereres, distribueres og opbevares sikkert.

---

## 5. Signup og anti-abuse

### 5.1 Kontooprettelse via MobilePay

#### Baggrund for beslutningen
Gratis email-tjenester tiltrækker spammere der massopretter konti. Traditionelle løsninger (CAPTCHA, email-verifikation) er nemme at omgå. Telefonverifikation virker, men kræver at HeidiMail gemmer telefonnumre — hvilket konflikter med privacy-narrativet.

#### Løsning
Kontooprettelse kræver en MobilePay-betaling på 1 kr.

#### Hvorfor dette virker
- **Anti-spam:** MobilePay kræver en MitID-verificeret konto (som kræver CPR-nummer). Spammere kan ikke massoprette MobilePay-konti.
- **Privacy:** HeidiMail gemmer KUN transaktions-ID'et — ikke telefonnummer, ikke navn, ikke CPR. Identifikation af brugeren kræver en separat editionskendelse til Vipps MobilePay.
- **Minimal friktion:** MobilePay er allestedsnærværende i Danmark. 1 kr. er en ubetydelig omkostning.
- **Troværdighed:** HeidiMail har mindre persondata om brugeren end Proton Mail (der kræver telefonnummer eller betalingskort).

#### Hvad sker der med den 1 kr.?
To muligheder (beslutning endnu ikke taget):
1. Krediteres brugerens konto som saldo
2. Doneres til en dansk privacy-organisation (branding-effekt)

#### Krav
- CVR-nummer (selskab skal oprettes)
- MobilePay-erhvervsaftale
- Integration med Vipps MobilePay API
- Estimeret budget for selskab + aftale: ca. 20.000 kr.

#### Begrænsning
- Udelukker ikke-danske brugere (ingen MobilePay). Acceptabelt for launch — HeidiMail starter dansk. International signup kan tilføjes senere via andre betalingsmetoder.

### 5.2 Rate limiting for nye konti

Selv med MobilePay-verifikation implementeres aggressiv rate limiting for nye konti som ekstra sikkerhedslag:

- **Første 24 timer:** Maks 10 udgående emails
- **Første 7 dage:** Maks 30 udgående emails
- **Derefter:** Gradvis optrapning baseret på kontoadfærd

Kombiner med overvågning af bounce-rates og spam-rapporter per konto. Konti med høj bounce-rate eller spam-rapporter suspenderes automatisk.

### 5.3 Abuse-håndtering

- abuse@heidimail.dk skal oprettes og overvåges
- System til at detektere og lukke misbrugskonti
- Procedure for håndtering af abuse-rapporter fra andre mailservere
- Vigtigt for at beskytte domænets og IP'ens reputation

---

## 6. Juridisk og compliance

### 6.1 GDPR-dokumentation

HeidiMail behandler persondata (emails er per definition persondata). Følgende dokumentation SKAL være på plads ved launch:

- **Privatlivspolitik:** Hvad gemmes, hvor længe, på hvilket lovgrundlag
- **Fortegnelse over behandlingsaktiviteter:** Lovpligtigt dokument
- **Procedure for indsigtsanmodninger:** En bruger beder om alle sine data
- **Procedure for sletningsanmodninger:** Retten til at blive glemt
- **Databehandleraftaler (DPA):** Med alle underleverandører der rører brugerdata (datacenter, backup-udbyder, evt. SMS-gateway til 2FA osv.)

HeidiMail sælger privacy — forventningerne til egen compliance er dermed ekstra høje.

### 6.2 Editionskendelser

Dansk politi kan med en retskendelse kræve udlevering af en brugers mails. Dette er lovpligtigt at overholde.

Procedure skal defineres:
- Hvem i organisationen håndterer det?
- Hvordan verificeres at kendelsen er gyldig?
- Hvad logges?
- Hvad informeres brugeren om?

**Vigtig strategisk note:** I fase 1-2 (uden E2E at rest) KAN HeidiMail læse og udlevere mails. I fase 3 (med valgfri E2E at rest) kan HeidiMail svare at de teknisk set ikke kan dekryptere indholdet for brugere der har aktiveret E2E.

### 6.3 Selskab og erhvervsaftaler

- CVR-nummer (ApS eller IVS)
- Erhvervskonto i bank
- MobilePay-erhvervsaftale
- Estimeret opstartsbudget: ca. 20.000 kr.

---

## 7. Infrastruktur og drift

### 7.1 Hosting

Stalwart Mail Server skal hostes i et dansk datacenter. Troværdighed kræver at det ikke er en amerikansk cloud-udbyder (ikke AWS, Azure, GCP, Hetzner).

Mulige danske udbydere (skal evalueres):
- Netgroup
- GlobalConnect
- Dansk datacenter-udbyder med relevant certificering

### 7.2 Deliverability

heidimail.dk har ingen email-reputation ved launch. Dette er en kritisk udfordring:

- Mails til Gmail/Outlook vil sandsynligvis lande i spam de første uger/måneder
- IP-reputation skal opvarmes gradvist
- Perfekt DKIM/SPF/DMARC er en forudsætning
- Overvej dedikeret IP-range med clean reputation
- Soft launch med lukket beta anbefales for at opvarme reputation før offentlig lancering

### 7.3 Backup og disaster recovery

- Brugere accepterer IKKE datatab på email
- Backup-strategi skal defineres (lokal backup i dansk datacenter, ikke cloud)
- Disaster recovery plan skal testes

---

## 8. Konkurrentlandskab

### 8.1 Privacy-email udbydere (ingen collaboration)

| Udbyder | Land | E2E | Collab | Chat | Brugere |
|---------|------|-----|--------|------|---------|
| Proton Mail | Schweiz | Ja | Nej | Nej | 100+ mio. |
| Tuta Mail | Tyskland | Ja | Nej | Nej | 10+ mio. |
| Mailbox.org | Tyskland | Delvist | Nej | Nej | Ukendt |
| Posteo | Tyskland | Delvist | Nej | Nej | Ukendt |

**Styrke:** Stærk privacy og kryptering.
**Svaghed:** Ingen samarbejdsfunktioner. Brugere der har brug for collaboration skal stadig bruge Google/Microsoft ved siden af.

### 8.2 Collaboration-platforme (ingen privacy)

| Udbyder | Land | E2E | Collab | Chat |
|---------|------|-----|--------|------|
| Gmail/Google Workspace | USA | Nej | Ja (Docs) | Ja (Chat) |
| Outlook/Microsoft 365 | USA | Nej | Ja | Ja (Teams) |

**Styrke:** Fuldt integreret suite med collaboration, chat, kalender, storage.
**Svaghed:** Underlagt CLOUD Act. Ikke GDPR-compliant i streng fortolkning. Brugerdata scannes/anvendes.

### 8.3 HeidiMails position

Ingen udbyder kombinerer:
- ✅ Privacy/datasuverænitet
- ✅ Kollaborativ email-redigering
- ✅ Integreret chat
- ✅ Dansk jurisdiktion

Dette er hullet HeidiMail udfylder.

### 8.4 Trusler

- Proton Mail kan tilføje collaboration-features
- Google/Microsoft lancerer "suveræne cloud"-tilbud målrettet EU (men er stadig underlagt CLOUD Act)
- Politisk medvind kan aftage hvis geopolitiske spændinger reduceres
- Deliverability-problemer ved launch kan skade tidlig adoption

---

## 9. Roadmap og faser

### Fase 1: Launch — "Dansk email + chat"

**Mål:** Funktionelt produkt på markedet med email og chat.

**Salgsargument:** "Dansk email på danske servere med integreret chat. Dine data forlader aldrig Danmark."

#### Leverancer

| # | Leverance | Status | Prioritet | Kompleksitet |
|---|-----------|--------|-----------|-------------|
| 1.1 | Email (Stalwart + webclient) | KLAR | — | — |
| 1.1b | Totrinsbekræftelse (2FA/TOTP) | KLAR | — | — |
| 1.2 | Chat: SignalR hub + grupper | Skal bygges | Høj | Medium |
| 1.3 | Chat: Kontekstuel chat (knyttet til email) | Skal bygges | Høj | Medium |
| 1.4 | Chat: Ad hoc chat | Skal bygges | Høj | Lav |
| 1.5 | Chat: Notifikationer | Skal bygges | Høj | Medium |
| 1.6 | Chat: Chathistorik persistens | Skal bygges | Høj | Lav-Medium |
| 1.7 | Signup: MobilePay-integration | Skal bygges | Høj | Lav |
| 1.8 | Signup: Rate limiting for nye konti | Skal bygges | Høj | Lav |
| 1.9 | Abuse: abuse@heidimail.dk + overvågning | Skal opsættes | Høj | Lav |
| 1.10 | Infra: Dansk datacenter hosting | Skal afklares | Høj | Medium |
| 1.11 | Infra: IP/domæne reputation opvarmning | Ved launch | Høj | Langvarig |
| 1.12 | Juridisk: CVR, selskab, MobilePay-erhverv | Skal oprettes | Høj | Administrativt |
| 1.13 | Juridisk: Privatlivspolitik | Skal skrives | Høj | Medium |
| 1.14 | Juridisk: Fortegnelse over behandlingsaktiviteter | Skal skrives | Høj | Medium |
| 1.15 | Juridisk: Abuse-procedure | Skal defineres | Medium | Lav |
| 1.16 | Juridisk: Procedure for editionskendelser | Skal defineres | Medium | Lav |
| 1.17 | Juridisk: Databehandleraftaler med leverandører | Skal indgås | Høj | Medium |
| 1.18 | Landing page + branding | Skal bygges | Høj | Medium |
| 1.19 | Soft launch / lukket beta | Ved launch | Høj | — |

#### Afhængigheder
- 1.7 (MobilePay) kræver 1.12 (CVR/selskab) først
- 1.11 (reputation) kræver 1.10 (hosting) først
- 1.19 (beta) kræver alt andet

---

### Fase 2: Collaboration — "Skriv emails sammen"

**Mål:** Tilføj kollaborativ email-redigering og B2B-features.

**Salgsargument:** "Skriv emails sammen i realtid — uden at forlade HeidiMail."

#### Leverancer

| # | Leverance | Prioritet | Kompleksitet |
|---|-----------|-----------|-------------|
| 2.1 | Collab: Cursor/badge broadcasting i email-body | Høj | Medium |
| 2.2 | Collab: Realtids tekst-broadcasting | Høj | Medium-Høj |
| 2.3 | Collab: Chat-sidebar integration ved redigering | Høj | Lav (bygger på fase 1) |
| 2.4 | Collab: "Start samarbejde"-flow fra email | Høj | Medium |
| 2.5 | Collab: Evt. afsnitsbaseret soft-locking (visuel) | Lav | Medium |
| 2.6 | B2B: Custom domains support | Medium | Medium-Høj |
| 2.7 | Forbedret spam-filtrering baseret på driftserfaringer | Medium | Løbende |

#### Afhængigheder
- 2.1-2.4 kræver at chat (fase 1) er stabil og i produktion
- 2.6 (custom domains) er uafhængig og kan bygges parallelt

---

### Fase 3: E2E-kryptering — "Selv vi kan ikke læse dine mails"

**Mål:** Valgfri end-to-end kryptering at rest med native apps.

**Salgsargument:** "Selv med en retskendelse kan vi teknisk ikke læse dine mails."

#### Leverancer

| # | Leverance | Prioritet | Kompleksitet |
|---|-----------|-----------|-------------|
| 3.1 | Native desktop-app (Electron el. lign.) | Høj | Høj |
| 3.2 | Native mobil-app (iOS + Android) | Høj | Høj |
| 3.3 | Lokal storage og søgeindeksering i app | Høj | Høj |
| 3.4 | Progressiv indeksering ved ny enhed | Høj | Medium |
| 3.5 | Nøglegenerering og key management | Høj | Høj |
| 3.6 | Kryptering at rest på server | Høj | Høj |
| 3.7 | Dekryptering i klient | Høj | Høj |
| 3.8 | Recovery key / recovery phrase | Høj | Medium |
| 3.9 | Multi-device nøgle-synkronisering | Høj | Høj |
| 3.10 | Toggle: Bruger vælger E2E til/fra | Medium | Medium |

#### Afhængigheder
- Hele fase 3 kræver at fase 1 og 2 er stabile
- 3.3-3.4 kræver 3.1-3.2 (native apps)
- 3.6-3.7 kræver 3.5 (key management)

---

## 10. Principper og designbeslutninger

### 10.1 Ærlighed i markedsføring
Markedsføring skal være præcis om sikkerhedsniveauet i hver fase. "Data hostet i Danmark" er ikke det samme som "end-to-end krypteret." Troværdighed er alt i privacy-markedet.

### 10.2 Open source (anbefalet)
Troværdighed i privacy-markedet kræver gennemsigtighed. Open source-kode er næsten en forudsætning for at privacy-bevidste brugere og organisationer stoler på produktet. Beslutning om open source skal tages.

### 10.3 Pragmatisme over perfektion
Hellere et godt produkt på markedet end et perfekt produkt der aldrig lancerer. Fase 1 behøver ikke E2E — dansk jurisdiktion alene er et stærkt argument. Chat behøver ikke være Slack — det skal bare virke. Collaboration behøver ikke være Google Docs — cursor-broadcasting + chat er nok.

### 10.4 Kun HeidiMail-brugere i samarbejdsfeatures
Chat og collaboration er kun tilgængelig for HeidiMail-brugere. Ingen gæsteadgang. Dette simplificerer alt og skaber viral vækst.

### 10.5 MobilePay som privacy-respekterende identity verification
Ved at bruge MobilePay til verifikation (og kun gemme transaktions-ID) opnår HeidiMail stærk anti-spam-beskyttelse med minimal persondata-indsamling. HeidiMail har potentielt mindre data om brugeren end nogen anden email-udbyder.

---

## 11. Teknisk stack (opsummering)

| Komponent | Teknologi |
|-----------|-----------|
| Email-server | Stalwart Mail Server (Rust) |
| Webclient | .NET Core (inkl. 2FA/TOTP) |
| Chat transport | SignalR (WebSocket) |
| Collab transport | SignalR (samme som chat) |
| Signup-verifikation | Vipps MobilePay API |
| Database | SQL Server eller PostgreSQL |
| Hosting | Dansk datacenter (TBD) |
| Native apps (fase 3) | TBD (Electron, MAUI, eller lign.) |

---

## 12. Åbne spørgsmål

Følgende beslutninger er endnu ikke taget og skal afklares:

1. **Pricing:** Hvad koster det? Gratis tier + betaling, eller kun betaling?
2. **Open source:** Skal koden open sources? Hvornår?
3. **Datacenter-udbyder:** Hvilken dansk udbyder?
4. **1 kr. MobilePay:** Kredit på konto eller donation?
5. **Landing page / branding:** Design og messaging
6. **Beta-strategi:** Hvem inviteres til lukket beta? Hvor mange?
7. **Kalender/kontakter:** Skal HeidiMail tilbyde kalender og kontakter (som Proton)?
8. **Vedhæftninger:** Størrelsesbegrænsninger? Storage per bruger?
9. **Native app-teknologi (fase 3):** Electron, .NET MAUI, Flutter, eller native?
10. **International expansion:** Hvornår og hvordan? Nordiske lande først?

---

## 13. Risici

| Risiko | Sandsynlighed | Impact | Mitigering |
|--------|--------------|--------|-----------|
| Deliverability-problemer ved launch | Høj | Høj | Soft launch, gradvis IP-opvarmning, lukket beta |
| Spammere misbruger tjenesten | Medium | Høj | MobilePay-verifikation + rate limiting |
| Proton Mail tilføjer collaboration | Medium | Medium | First-mover i dansk marked, fokus på integration |
| For få brugere til at chat/collab giver værdi | Medium | Høj | B2B-fokus hvor hele teams onboarder |
| Teknisk nedbrud / datatab | Lav | Kritisk | Backup, disaster recovery, overvågning |
| Juridisk: Manglende GDPR-compliance | Lav | Kritisk | Juridisk rådgivning, dokumentation |
| Politisk medvind aftager | Lav | Medium | Produkt skal stå på egne ben, ikke kun timing |

---

## 14. Succeskriterier

### Fase 1 (6 måneder efter launch)
- HeidiMail er live og stabil
- Chat fungerer i produktion
- Mails leveres pålideligt til Gmail/Outlook (>95% inbox rate)
- Minimum 500 aktive brugere
- Ingen større sikkerhedsincidenter

### Fase 2 (12 måneder efter launch)
- Kollaborativ redigering fungerer i produktion
- Custom domains tilbydes til B2B
- Minimum 2.000 aktive brugere
- Mindst 5 betalende virksomheder

### Fase 3 (18-24 måneder efter launch)
- Native apps tilgængelige (desktop + mobil)
- Valgfri E2E-kryptering at rest tilbydes
- Minimum 10.000 aktive brugere