Case: software til droneoperatører (Dronelog)

Software til droneoperatører skal først og fremmest gøre det let at dokumentere hvem der fløj, med hvilken drone, hvor og under hvilken tilladelse. EU's droneregler stiller krav til både operatøren, piloten og dronen, og en god platform samler det hele ét sted, så papirarbejdet ikke æder tiden mellem flyvningerne. Her gennemgår jeg mit arbejde for Dronelog: opgaven, de valg den krævede, og hvad du kan tage med hvis du selv overvejer en platform til en branche med egne regler.

[PLACEHOLDER: Bekræft skriftlig tilladelse fra Dronelog til navn, logo og evt. citat. Ellers anonymiseres casen, og titel og slug ændres.]

Den korte version

Projekt	Detaljer
Kunde	Dronelog, [PLACEHOLDER: én linje om hvad Dronelog er og laver]
Brugere	[PLACEHOLDER: hvem bruger platformen, fx erhvervsoperatører eller enkeltpiloter]
Opgave	[PLACEHOLDER: hvad der skulle bygges eller videreudvikles]
Min rolle	[PLACEHOLDER: fx hele løsningen, bestemte funktioner, integrationer eller vedligehold]
Teknologi	[PLACEHOLDER: stack og hosting]
Periode	[PLACEHOLDER: hvornår og hvor længe]
Resultat	[PLACEHOLDER: målbart udfald, kun tal Dronelog har godkendt]

[PLACEHOLDER: 2-3 sætninger i dine egne ord om problemet før projektet, hvad der blev bygget, og hvad det betød for brugerne.]

Casen hører til en række indlæg om projekter jeg har arbejdet på. Læs også om produktvalg og prioriteringer i fra idé til SaaS: valg og prioriteringer.

Hvad droneoperatører har brug for fra deres software

Før jeg bygger noget til en branche, skal jeg forstå de regler den arbejder under. For droner er det EU's fælles regler, som EASA deler op i tre kategorier: den åbne kategori med lav risiko, den specifikke kategori med middel risiko og den certificerede kategori med høj risiko. I den åbne kategori flyves der under 120 meter, og reglerne afhænger af hvor tæt dronen kommer på mennesker.

Flyvninger uden for de rammer, fx uden for synsvidde, over 120 meter eller med droner over 25 kg, hører til i den specifikke kategori. Her skal operatøren have en tilladelse fra den nationale luftfartsmyndighed eller indsende en erklæring efter et standardscenarie, og der skal ligge en operationsmanual, som EASA forklarer på sin side om den specifikke kategori. I Danmark skal en organisation der flyver erhvervsmæssigt desuden være registreret som droneoperatør hos Trafikstyrelsen, og operatørnummeret skal stå læsbart på alle de droner organisationen flyver med.

Oversat til software betyder det typisk at platformen skal holde styr på:

piloter og deres certifikater og uddannelse
droner, deres klasse, operatørmærkning og vedligehold
tilladelser og erklæringer og de rammer de sætter for flyvningerne
flyvninger: hvem, hvad, hvor, hvornår og under hvilken kategori
hændelser og afvigelser, så de kan følges op

Det er min læsning af reglerne som udvikler, ikke juridisk rådgivning. Hvilke krav der gælder for den enkelte operatør, afhænger af typen af flyvning og afklares med myndigheden eller en rådgiver.

[PLACEHOLDER: Hvilke af disse behov Dronelog-platformen dækker, og hvilke den bevidst ikke dækker.]

Opgaven: hvad Dronelog havde brug for

Når jeg starter på en platform til en niche, bruger jeg den første tid på at forstå arbejdsgangen, ikke på at tegne skærmbilleder. Hvad sker der fra en opgave kommer ind, til dronen er pakket sammen igen, og hvor opstår dobbeltarbejde eller huller i dokumentationen?

[PLACEHOLDER: Udgangspunktet og målet. Hvordan løste brugerne opgaven før (regneark, papirlogbøger, ældre system), og hvad skulle første version kunne?]

[PLACEHOLDER: Hvordan du kom ind i projektet, og hvad du stod for. Prosa i første person.]

De vigtigste beslutninger i projektet

Fire valg fylder i næsten alle platforme til droneoperatører. Under hvert står hvorfor det betyder noget, og hvad Dronelog valgte.

Regler som data, ikke som kode

Droneregler ændrer sig. Erklæringer efter de europæiske standardscenarier har fx kun kunnet bruges siden 1. januar 2024, ifølge EASA. Hvis kategorier, højdegrænser og krav til piloter er skrevet direkte ind i koden, kræver hver regelændring en udvikler. Ligger de som data, kan en administrator opdatere dem, og en gammel flyvning kan stadig vises under de regler der gjaldt dengang.

[PLACEHOLDER: Hvordan regler og krav blev håndteret i Dronelog, og om løsningen holdt.]

Roller og rettigheder

En operatør er sjældent én person. Der er typisk en ansvarlig for operationerne, piloter der flyver, og måske en kunde der skal kunne se dokumentationen. Hvem må oprette flyvninger, hvem må godkende dem, og hvem må kun læse? Det er langt nemmere at designe fra start end at bygge ind bagefter, og jeg har skrevet en guide til brugerroller og rettigheder i SaaS om netop det.

[PLACEHOLDER: Hvilke roller platformen har, og hvordan adgang er delt mellem organisationer.]

Brug i felten

Dokumentationen opstår ved startstedet, ikke ved skrivebordet. Skal en pilot bruge fem minutter på en telefon i blæst og sollys for at logge en flyvning, bliver det gjort bagefter eller slet ikke. Det kræver store knapper, få obligatoriske felter, fornuftige standardværdier og en plan for hvad der sker når dækningen er dårlig.

[PLACEHOLDER: Bruges platformen på mobil i felten, også offline, og hvad virkede?]

Data der kan vises frem

Dokumentation skal kunne vises til en kunde, et forsikringsselskab eller en myndighed. Derfor skal data kunne trækkes ud i en form andre kan læse, fx som rapport pr. flyvning eller pr. periode. Og de skal kunne stoles på: hvem har ændret hvad, og hvornår.

[PLACEHOLDER: Rapporter, eksport eller integrationer i Dronelog, hvis relevant.]

Resultatet og hvad jeg ville gøre anderledes

Jeg måler en platform som denne på om den bliver brugt i hverdagen. En logbog som piloterne springer over, er værdiløs uanset hvor mange funktioner den har.

[PLACEHOLDER: Hvad blev leveret, og hvornår kom det i brug?]

[PLACEHOLDER: Målbare resultater som Dronelog har godkendt at dele, fx antal brugere, sparet tid eller færre fejl i dokumentationen. Ingen tal uden godkendelse.]

[PLACEHOLDER: Evt. citat fra Dronelog med navn og titel, kun med skriftlig tilladelse.]

[PLACEHOLDER: Én eller to ting du ville gøre anderledes i dag, og hvorfor. Skriv det som prosa, gerne med det der gik galt undervejs.]

Hvad du kan lære, hvis du vil bygge en nicheplatform

Et projekt som Dronelog ligner mange andre platforme til regulerede brancher, fra el og VVS til transport og sundhed. Fire ting går igen:

Start med arbejdsgangen, ikke funktionslisten. Følg en bruger gennem en hel opgave før du beslutter hvad systemet skal kunne.
Byg første version smalt: én brugertype og én arbejdsgang der virker helt. Det er tankegangen bag min MVP-proces uge for uge.
Lad regler, grænser og krav ligge som data, så de kan ændres uden en ny udgivelse.
Hav en fagperson tæt på projektet. En pilot eller driftsansvarlig der tester hver uge, fanger flere fejl end nogen kravspecifikation.

Vil du se en anden case fra serien, så læs casen om funktioner til en medarbejderplatform i vækst.

Hvornår en specialbygget platform er det forkerte valg

Findes der allerede et færdigt system til logbog og flådestyring der dækker det meste af dit behov, er det næsten altid billigere at købe det. En specialbygget platform betaler sig først når arbejdsgangen er din konkurrencefordel, når standardsystemerne tvinger dig til omveje hver dag, eller når platformen selv er det produkt du vil sælge.

Skal softwaren styre selve dronen, behandle sensordata i realtid eller indgå i certificeret luftfart, er det et andet speciale end mit. Jeg bygger webplatforme og SaaS, ikke firmware eller flysikkerhedssystemer. Der er du bedre tjent med en specialist.

Næste skridt

Har du en idé til software til en niche, er første skridt at beskrive arbejdsgangen og hvem der skal bruge løsningen. Du behøver ikke en kravspecifikation. Større projekter starter hos mig med et betalt forprojekt til fast pris, hvor opgaven bliver afgrænset og prissat, og du ejer koden fra første dag.

Du kan se hvordan et forløb med mig foregår fra første opkald til lancering, og hvad jeg tilbyder inden for udvikling af SaaS og nicheplatforme.

Ofte stillede spørgsmål

Hvad koster det at få bygget software til droneoperatører?

Det afhænger af omfanget, og et seriøst bud kræver at opgaven er afgrænset først. De største prisdrivere er antallet af brugertyper, hvor meget der skal virke i felten, integrationer til fx kort eller vejrdata, og hvor meget rapportering der skal med. Derfor starter jeg større projekter med et betalt forprojekt til fast pris, så du får en pris du kan træffe beslutning på.

Kan en platform bygget til danske regler bruges i resten af EU?

Ja, i vid udstrækning, fordi reglerne for den åbne og den specifikke kategori er fælles i EU. Forskellene ligger især i nationale processer, sprog, kontakten til myndighederne og lokale zoner hvor der gælder særlige regler. Byg de landespecifikke dele som konfiguration fra start, og få de lokale krav afklaret med en rådgiver før du udvider til et nyt land.

Skal en droneplatform kunne virke uden netforbindelse?

Det afhænger af hvor der flyves. Flyver piloterne ofte i områder med dårlig dækning, er det en fordel at kunne gemme data på telefonen og synkronisere bagefter. Fuld offline-understøttelse gør løsningen dyrere at bygge og teste, så jeg anbefaler typisk at starte med kladder der gemmes lokalt, og kun bygge mere hvis behovet viser sig at være reelt.

Hvem ejer koden når platformen er færdig?

Det gør du. Hos mig ejer kunden koden fra første dag, og den bør ligge i et repository (kodearkiv) som din virksomhed har adgang til. Det samme bør gælde domæne, hosting og tredjepartstjenester. Så kan du skifte udvikler eller tage udviklingen internt uden at starte forfra, og du er ikke afhængig af én person.