Hvorfor abonnement i stedet for engangsbetaling?

Nogle gange får jeg spørgsmålet: "Hvorfor ikke bare en engangsbetaling på 29 kr?" Det er et helt fair spørgsmål, og svaret ligger i kompleksiteten bag det, der ser ud til at være simple features.

Lad mig give dig et eksempel: "Book TeleBus" knappen. På overfladen ser det ud til at være en simpel opgave – bare en knap der åbner en formular eller ringer til et nummer. Men i virkeligheden er det langt mere komplekst.

Hvad ser du, når du klikker på "Book TeleBus"?

Du ser en knap. Måske en formular. Måske et telefonnummer. Det er det. Men bag kulisserne sker der meget mere:

• Systemet skal vide, hvilken rute du rejser på – og forskellige ruter har forskellige tidsfrister
• Afhentning i Sælvig kræver 45 minutter, mens kørsel til Sælvig kræver 2 timer før ankomst
• Telefonerne har forskellige åbningstider: mandag-fredag 7-21, lørdag 8-19, søndag 8-21
• Email kan kun bruges hverdage 8-16, og der skal være 14 minutter buffer til behandling
• Systemet skal håndtere nat-overgange, weekender og helligdage
• UI'en skal skifte dynamisk baseret på om der er nok tid, om email kan bruges, eller om telefon er nødvendig

Edge cases der blev opdaget under udvikling

Under implementeringen opdagede jeg edge cases, jeg ikke havde tænkt på først:

• Søndag kl 7:00 problem: Hvis du prøver at booke søndag kl 7:00 til en ankomst kl 8:00, kan du ikke ringe før telefon åbner kl 8:00. Der er 0 minutter fra åbning til ankomst – ikke nok tid.
• Fredag aften booking: Hvis du booker fredag kl 23:00 til en lørdag-afgang, åbner email først mandag kl 8:00. Systemet skal tjekke om email'en vil blive læst i tide.
• Forskellige tidsfrister: Først implementerede jeg 45 minutter for alle Sælvig-afgange, men det skulle være 2 timer for afgange TIL Sælvig (fordi bussen skal være klar når færgen ankommer).

Hvad krævede det?

For at implementere "Book TeleBus" knappen rigtigt:

• 1.230 linjer nye kode (26 linjer fjernet)
• 7 filer ændret
• 12 test cases der dækker alle edge cases
• Kompleks valideringslogik der tjekker tidsfrister, åbningstider, weekender, nat-overgange
• Dynamisk UI der tilpasser sig baseret på validering

Og det er kun én feature. Hver ny funktion i Ø-kort+ kræver samme niveau af omhu og testning for at sikre, at den virker korrekt i alle situationer.

Hvorfor abonnement?

Når jeg bygger features til Ø-kort+, går jeg ikke på kompromis med kvaliteten. Jeg tester edge cases, håndterer alle scenarier og sikrer, at funktionerne virker korrekt – også når det er søndag kl 7:00, fredag aften eller nat-overgange.

En engangsbetaling på 29 kr dækker ikke den indsats, der ligger i at bygge og vedligeholde features af denne kvalitet. Abonnementsmodellen giver mig mulighed for at:

• Investere den tid, det kræver at bygge features rigtigt
• Teste grundigt og håndtere edge cases
• Vedligeholde og forbedre funktionerne løbende
• Lytte til feedback og tilpasse appen efter brugernes behov

Det betyder ikke, at jeg bygger features for at fylde tiden. Det betyder, at når jeg bygger en feature, gør jeg det rigtigt – også når det kræver 1.200+ linjer kode for en knap, der ser simpel ud.

Ø-kort+ er min måde at sikre, at jeg kan fortsætte med at bygge features af høj kvalitet, der virker korrekt i alle situationer.