Udvikling af web app fra start til slut – live eksempel

Kan man finde steder at sidde i solen og nyde en drink og få noget mad?

Det var egentlig bare det spørgsmål, det hele startede med...

Du kender det sikkert.

Du er i en ny by. En ven siger: “Jeg vil gerne sidde i solen og spise.”
Ingen af jer ved helt hvor. I åbner Google Maps, scroller rundt, vælger et sted… og når I endelig sætter jer, er solen allerede forsvundet bag en bygning.

Så i stedet for bare at snakke om det, tænkte jeg:
lad os bygge en web app, der løser præcis det problem.

Det her er ikke et poleret case study.

Det er udvikling af app i realtid, med fejl, frustrationer og justeringer undervejs.

Du kan også se hele videoen på youtube her:
https://youtu.be/e8Xr-KKI5OU?si=NZ3q221oiSCbmdSt

Idéen: en simpel web app der viser sol eller skygge

Idéen er faktisk meget enkel:

• Vis restauranter på et kort
• Vis kun dem, der har terrasse eller mulighed for at sidde ude
• Vis om der er sol eller skygge på et bestemt tidspunkt

Ikke noget med skyddække, vindretning eller vejrmodeller.
Bare: hvor står solen, og rammer den restauranten?

Det er klassisk web app-udvikling:
et konkret problem, en klar brugeropgave.

Mobile first – ingen login, ingen admin

Jeg beslutter ret hurtigt nogle rammer:

• Mobile first (folk bruger den på farten)
• Offentlig app, ingen login
• Map view + list view
• Brug Google Maps / Places
• Brug solens position til at estimere sol/skygge

Det er en MVP. Ikke et enterprise-system.

Første skridt: beskriv appen og lad systemet bygge

Jeg starter som jeg ofte gør i dag:

Jeg skriver hele idéen ned i én prompt.

“Jeg vil gerne lave en mobile first web app.
Den skal vise restauranter på et kort og i en liste.
Den skal vise om restauranter ligger i sol eller skygge
på et bestemt tidspunkt på dagen.
Ingen login. Ingen admin. Bare offentligt.”

Og så beder jeg systemet bygge det i Lovable.

Det er her udvikling af web app virkelig bliver interessant:
du får lynhurtigt noget, du kan reagere på.

OBS. Hvis det kræver mere planlægning, kan du også bruge fx ChatGPT til at komme igang og få spariing.

Første output: “det virker… næsten”

Appen bliver bygget.

Jeg ser:

• et kort
• nogle restaurant-markers
• en form for sol-status

Men selvfølgelig mangler der noget.

Den beder om API keys:

• Google Places API
• Google Maps API

Fair nok. Det er virkeligheden.

Google Cloud: her begynder den klassiske friktion

Jeg hopper ind i Google Cloud Console.

Og hvis du nogensinde har lavet udvikling af app, kender du det her:

• forkert projekt valgt
• “you do not have permission”
• APIs der ikke er enabled
• gamle vs nye API’er

Efter lidt trial & error finder jeg ud af:
👉 det er “Places API (New)” der skal bruges

Det er sådan noget, der ikke står tydeligt nogen steder –
men som man altid løber ind i, når man bygger rigtige apps.

Appen loader – men alt siger “ingen sol”

Kortet loader. København dukker op. Restauranter vises.

Men:
alle steder er markeret som ingen sol.

Og ja… det er aften, så det giver egentlig mening.
Men det afslører også noget vigtigt:

Vi mangler:

• mulighed for at ændre tidspunkt
• mulighed for at søge efter andre byer
• tydeligere visuel feedback

Hurtig realitet: hvad irriterer mig mest lige nu?

Efter 5 minutter har jeg en klar liste:

1. Search virker dårligt
2. List view ligger mærkeligt
3. Sol/skygge er svært at aflæse
4. Farver skifter konstant
5. UI føles rodet på mobil

Det er meget normalt i udvikling af web app:

først får du noget der virker teknisk –
så opdager du alt det, der ikke virker for brugeren.

Gør det simpelt: orange = sol, grå = skygge

Næste skridt er at skære ind til benet.

Jeg beder systemet om:

• Orange markers = sol
• Grå markers = skygge
• Brug solens position baseret på tidspunkt
• Antag skyfrit vejr

Nu begynder appen at give mening.

Den er stadig upræcis –
men den kommunikerer tydeligt, hvad der sker.

Når præcision bliver fristende (og farlig)

Her kommer det klassiske produkt-dilemma:

Hvor præcist skal det være for, at skabe værdi (specielt som MVP)?

For at være mere præcis, skal vi tage højde for:

• bygninger
• skygger
• højder
• bystruktur

Vi prøver, bare for at se.

Pludselig:

• skygger renderes på kortet
• solområder beregnes mere realistisk

Men:

• appen bliver tung
• loading er langsom
• overblikket forsvinder

UX-beslutning: fjern skyggerne igen

Det her er en vigtig læring.

Bare fordi noget er teknisk fedt, betyder det ikke,
at det er godt for brugeren.

Jeg beslutter:

• fjern visuelle skygger
• behold kun resultatet (sol/skygge)

Nu føles appen igen let og forståelig.

List view: her begynder appen at give rigtig mening

Noget af det første, jeg opdager, er faktisk lidt sjovt.

I list view kan vi allerede se langt mere data end på kortet:

• billeder af restauranten
• åbnings­tider
• prisniveau
• ratings

Men på kortet?
Der ser vi kun navn og en lille markør.

Så næste oplagte skridt i udvikling af web app’en er:
at gøre de to views mere ensartede.

Når jeg klikker på en restaurant på kortet, skal jeg ikke føle,
at jeg mangler halvdelen af informationen.

UI-oprydning: alt det vigtige op i toppen

Der er også noget andet, der begynder at irritere mig mere og mere.

Search-feltet.
“Min placering”-knappen.
Tidspunktet.

De ligger spredt. Fylder for meget. Føles rodet, især på mobil.

Så jeg beder systemet om at:

• samle search, lokation og tid i én topbar
• gøre search small og centreret
• lade kortet få mest muligt plads

Det er en klassisk mobile-first beslutning:
brug skærmplads på det, der skaber værdi.

Efter den ændring føles appen markant mere “rigtig”.

Stabilitet: når farverne skifter for meget

Et af de mest frustrerende problemer dukker nu op.

Nogle gange er en restaurant:

• orange (sol)
• så grå (skygge)
• så orange igen

Ikke fordi solen flytter sig,
men fordi beregningen loader og opdaterer.

For en bruger føles det som en bug, også selvom logikken egentlig er korrekt.

Så vi stabiliserer:

• farverne må ikke flakke
• resultatet skal “låses”, når tidspunktet vælges
• først opdatere, når brugeren aktivt ændrer noget

Det her er vigtigt i udvikling af app:
brugeren skal stole på det, de ser.

Search + lokation: gør det brugbart i praksis

Nu kan man:

• søge efter en by (fx Barcelona)
• bruge sin nuværende lokation
• vælge tidspunkt på dagen

Og det begynder faktisk at give mening.

Barcelona kl. 12?
Der er steder i solen.

København kl. 16 i december?
Not so much, og det er også fair.

Det er ikke 100 % præcist,
men det er brugbar indsigt, og det er ofte nok.

Map view vs list view: to forskellige behov

Noget, der bliver meget tydeligt nu:

• Map view er til overblik og orientering
• List view er til beslutning

I list view kan man:

• se billeder
• vurdere stemning
• tjekke åbningstider
• få en fornemmelse af “kan vi sidde her?”

Så begge views har deres plads,
og det er en vigtig del af web app-design.

Hvor ender vi efter ~40 minutters kaos?

Vi ender faktisk med noget, der kan bruges:

• En mobile-first web app
• Kort med restauranter
• Sol / skygge markeret visuelt
• Søgning og lokation
• Tidsfilter
• List view med billeder og detaljer

Er det perfekt?
Nej.

Er det præcist nok til at træffe en beslutning?
Ofte ja.

Og det er pointen.

Hvad kunne man bygge videre på?

Hvis det her var et rigtigt produkt, ville næste skridt være:

• bedre data om terrasser
• tydeligere “confidence score” (hvor sikker er vi?)
• caching af beregninger
• filtrer: kun vis steder i sol
• gem favoritsteder

Men det er iteration.
Det vigtige er fundamentet.

Den vigtigste læring om udvikling af web app

Det her projekt viser meget godt,
hvordan udvikling af app i praksis ofte ser ud:

• du starter med en idé
• du bygger noget hurtigt
• du bliver irriteret
• du justerer
• du skærer fra
• og pludselig har du et tool

Ikke perfekt.
Men brugbart.

Og ofte er brugbart langt bedre end perfekt.

Afslutning

Det her var ikke en glat tutorial.
Det var vibe coding, følelserne ude på tøjet.

Men vi gik fra:

“kan man finde et sted i solen?”

til:

en fungerende web app med kort, data og valg.

Have det rigtig godt.

Code&Go hjælper virksomheder med at bygge stærke digitale produkter i en tid hvor AI ændrer spillereglerne for innovation, udvikling og vækst. Vi arbejder sammen med teams der vil skabe smartere løsninger, validere idéer hurtigere og bygge forretninger der kan skalere.

Har du brug for sparring eller hjælp til at løfte dit næste produkt eller AI projekt, så er du velkommen til at kontakte os på codego.dk og høre hvordan vi kan støtte din rejse.