Udvikling af webapplikationer: sådan griber I det an

Udvikling af webapplikationer handler om mere end sider og design. En webapplikation er et system, folk logger ind i og arbejder i: en kundeportal, et bookingsystem, et internt værktøj til ordrer eller sager. Her gennemgår vi, hvad der adskiller en webapplikation fra en hjemmeside, hvilke beslutninger der former løsningen, hvordan arbejdet forløber, og hvad der påvirker pris og tidsplan.

Det vigtigste først

• En webapplikation har brugere, roller, data og arbejdsgange. Det gør den til et andet projekt end en hjemmeside.
• De vigtigste valg er arkitektur, database, login og integrationer. De er dyre at ændre senere.
• Start med en lille første version, der løser én konkret opgave, og byg videre ud fra brugen.
• Sikkerhed, backup og overvågning skal planlægges fra start, ikke tilføjes til sidst.
• En webapplikation er aldrig helt færdig. Afsæt tid og budget til drift og vedligeholdelse.

Hvad adskiller en webapplikation fra en hjemmeside?

En hjemmeside viser information. De fleste besøgende læser, klikker og tager måske kontakt. En webapplikation lader brugerne gøre noget: oprette en sag, godkende en faktura, booke en tid eller følge en ordre. Det kræver fem ting, som en almindelig hjemmeside sjældent har:

• Login, så systemet ved, hvem brugeren er.
• Roller og rettigheder, så en kunde kun ser sine egne data, og en medarbejder kun kan det, vedkommende skal.
• Data, der gemmes, søges i og ændres over tid.
• Arbejdsgange med trin, statusser og notifikationer.
• Integrationer til ERP, CRM, betaling eller andre systemer.

Er det en hjemmeside, I har brug for, så handler budgettet om noget andet. Det har vi beskrevet i vores guide til webudvikling. Overvejer I, om et standardsystem kan gøre arbejdet, så læs artiklen om skræddersyet applikationsudvikling først.

De beslutninger, der former løsningen

Den første store beslutning er arkitekturen. Kort sagt kan siderne bygges på serveren og sendes færdige til browseren, eller browseren kan hente data og bygge skærmbillederne selv, en såkaldt single page-app. Serverrenderede sider er enkle, hurtige at åbne og nemme at få fundet i søgemaskiner. En single page-app føles mere som et program og passer til skærme med meget interaktion. Mange løsninger blander de to.

Bag skærmbillederne ligger backend og database. Backenden håndhæver reglerne: hvem må hvad, og hvad sker der, når en ordre skifter status. Databasen skal designes efter jeres data, ikke efter de første skærmbilleder. En relationsdatabase som PostgreSQL eller SQL Server passer til de fleste forretningssystemer.

Login er den tredje beslutning. Skal medarbejdere bruge den konto, de allerede har, er single sign-on med for eksempel Microsoft Entra ID ofte det rigtige valg. Kunder har brug for en sikker egen konto med mulighed for totrinsbekræftelse.

Integrationer, hosting og sikkerhed

De fleste webapplikationer skal tale med andre systemer. Kortlæg tidligt, hvilke data der skal flyde hvorhen, hvem der ejer dem, og hvad der skal ske, når et andet system ikke svarer. Findes der ikke et brugbart API, skal det måske bygges. Det er en del af vores API-udvikling.

Hosting vælges efter krav til drift og data. Uanset platform bør I have styr på adgangskontrol, kryptering, opdatering af afhængigheder, automatisk backup, der faktisk bliver testet, og overvågning, der giver besked, før brugerne gør. Har I særlige krav til, hvor data ligger, så sig det fra start. Det påvirker valget.

Sådan forløber udvikling af webapplikationer

Et forløb starter med en afklaring. Hvem er brugerne, hvilken opgave skal løses først, og hvordan ved I, at det virker? Resultatet er en kort beskrivelse, skitser af de vigtigste skærmbilleder og en prioriteret liste.

Derefter bygges en første version, en MVP, der løser den vigtigste opgave godt i stedet for alle opgaver halvt. Den kommer i hænderne på rigtige brugere, og der bygges videre i korte iterationer med en demo hver gang. Automatiske tests, kodereview og et testmiljø, der ligner produktion, kører hele vejen. Lanceringen planlægges med dataflytning, oplæring og en plan for at rulle tilbage.

Hvad påvirker pris og tidsplan?

Det er svært at sætte pris på en webapplikation, før omfanget er kendt. Disse forhold betyder mest:

• Antal brugertyper, roller og arbejdsgange.
• Antal integrationer, og hvor gode de andre systemers API’er er.
• Flytning af data fra et gammelt system.
• Krav til sikkerhed, dokumentation og tilgængelighed.
• Hvor hurtigt I kan træffe beslutninger og teste undervejs.

Den mest effektive måde at holde budgettet på er at holde den første version lille og lade brugen afgøre, hvad der bygges bagefter.

Sådan bygger vi webapplikationer

Vi bygger webapplikationer fra afklaring til drift: arkitektur, backend, database, brugerflade, integrationer og test. Det samler vores webudviklingstjenester og applikationsudvikling. Skal I hurtigt have noget foran brugerne, starter vi med en MVP, og har I brug for ekstra hænder i et eksisterende team, har vi full stack-udviklere, der arbejder i både front- og backend.

Aftal fra start, at I ejer kildekoden, og at den ligger i et repository, I selv har adgang til, sammen med dokumentation og opsætning af miljøerne.

Drift og vedligeholdelse efter lancering

Efter lanceringen begynder den del, der varer længst. Biblioteker og frameworks får sikkerhedsopdateringer, browsere ændrer sig, og brugerne beder om nye funktioner. Afsæt et fast beløb hver måned til opdateringer, overvågning og små forbedringer, så applikationen ikke forfalder. Det er præcis det, vores softwarevedligeholdelse dækker.

Ofte stillede spørgsmål

I praksis

God udvikling af webapplikationer starter med brugerne og den vigtigste opgave. Træf de store valg om arkitektur, data, login og integrationer bevidst, byg en lille første version, og lad brugen styre resten. Planlæg drift og vedligeholdelse fra dag ét, så applikationen også fungerer om nogle år.