Vibe coding-eksempler: 10 ekte apptyper, prompter og hva som gikk galt
De vanligste vibe coding-eksemplene er små, nyttige webapper: trackere, bookingsider, interne verktøy, kundeportaler, landingssider, quizer, dashbord og enkle KI-verktøy. Under finner du ti av dem. For hver ser du hvem som bygger den, første prompt, hva som vanligvis går galt, og oppfølgingsprompten som fikser det.
Dette er sammensatte eksempler på prosjektene folk oftest tar med seg til KI-appbyggere, ikke casestudier av én person. Promptene kan kopieres. Feilene er de som dukker opp igjen og igjen, og derfor er de den nyttige delen. Hvis vibe coding i seg selv er nytt for deg, start med hva vibe coding er.
1. En personlig budsjetttracker
Hvem bygger den: privatpersoner som har prøvd regneark og gitt opp.
Første prompt:
Bygg en månedlig budsjetttracker for meg. Jeg legger inn utgifter med beløp, kategori (mat, husleie, transport, moro, annet), dato og et notat. Vis månedens totaler per kategori som et stolpediagram og en liste over siste utgifter. Jeg kan sette et budsjett per kategori og se hvor mye som er igjen.
Hva gikk galt: diagrammet telte alle utgifter som noen gang var registrert, ikke bare denne måneden, så etter to måneder virket alle kategorier overbrukt. I tillegg ble beløp skrevet med komma ("1,200") lagret som 1.
Fiksprompt:
Diagrammet og totalene skal bare inkludere utgifter fra valgt måned. Legg til en månedsvelger øverst, som som standard står på inneværende måned. Godta også beløp skrevet med komma eller mellomrom, og lagre dem som tall.
Lærdom: «denne måneden» er en regel. Si reglene høyt.
2. En bookingside for en liten frisørsalong
Hvem bygger den: små bedriftseiere som er lei av å ta imot bookinger over telefon og DM.
Første prompt:
Bygg en bookingside for frisørsalongen min. Kunder velger en tjeneste, en dato og et ledig tidspunkt, og fyller inn navn og telefon. Jeg har en privat adminside, bak innlogging, som viser bookinger per dag.
Hva gikk galt: to kunder booket det samme klokkeslettet 10:00 med ett minutts mellomrom, fordi siden bare sjekket ledighet da den først ble lastet. En 90 minutter lang fargebehandling blokkerte heller ikke tidsrommene etter seg.
Fiksprompt:
Når en kunde sender inn en booking, sjekk på serveren at alle tidsrommene den dekker fortsatt er ledige, og avvis den med «Det tidspunktet ble nettopp tatt» hvis ikke. En tjeneste blokkerer hele sin lengde, så en 90-minutters booking kl. 10:00 blokkerer 10:00, 10:30 og 11:00.
Lærdom: alt to personer kan gjøre samtidig trenger en sjekk på serveren. Se hvordan bygge en bookingapp for hele versjonen.
3. En restaurantmeny med QR-kode
Hvem bygger den: kafé- og restauranteiere som skriver ut menyer for ofte.
Første prompt:
Bygg en mobilmenynettside for kafeen min. Seksjoner for frokost, lunsj, drikke og dessert, med hver rett med navn, pris, kort beskrivelse og kostholdsmerker (vegansk, glutenfri). Jeg trenger en adminside for å redigere retter og markere dem som utsolgt. Vis en QR-kode jeg kan skrive ut, som lenker til menyen.
Hva gikk galt: ingenting brøt sammen, men menyen var treg på kafeens Wi-Fi fordi fulle telefonbilder ble lastet for hver rett.
Fiksprompt:
Menybildene er for tunge. Endre størrelsen på opplastede bilder til maksimalt 800 px bredde, komprimer dem og last dem etter hvert som besøkende scroller.
Lærdom: test på et tregt nett, ikke bare på kontoret ditt.
4. Et utstyrs- eller lagerverktøy for et team
Hvem bygger den: driftsfolk som erstatter et delt regneark.
Første prompt:
Bygg et lagerverktøy for lagerteamet vårt. Varer har navn, SKU, antall, plassering og en minimumsbeholdning. Ansatte logger inn og kan legge til lager, fjerne lager med en årsak, og se en liste over varer under minimum uthevet i rødt. Før en historikk over alle endringer og hvem som gjorde dem.
Hva gikk galt: historikken viste «bruker 3» i stedet for navn, og å fjerne mer lager enn det som fantes gjorde antallet negativt.
Fiksprompt:
Vis personens navn i historikken, ikke ID-en. Ikke tillat et uttak som tar antallet under null; vis «Bare 4 på lager» i stedet.
Lærdom: beskriv hva som skal være umulig, ikke bare hva som skal være mulig. Vår guide om å bygge en lagerapp dekker resten.
5. En kundeportal for en frilanser eller et studio
Hvem bygger den: designere, regnskapsførere, konsulenter og byråer.
Første prompt:
Bygg en kundeportal. Jeg inviterer kunder via e-post. Hver kunde logger inn og ser bare sine egne prosjekter, filer og fakturaer, og kan legge igjen kommentarer. Jeg logger inn som admin og ser alt.
Hva gikk galt: dette er den viktigste feilen på listen. Sidene viste bare hver kunde sine egne prosjekter, men serveren returnerte et hvilket som helst prosjekt hvis du endret tallet i adressefeltet. Å klikke rundt som én kunde avdekket det aldri.
Fiksprompt:
Gå gjennom hver serverrute som returnerer prosjekter, filer, kommentarer eller fakturaer. Hver av dem må bekrefte at innlogget kunde eier posten, og ellers returnere «ikke funnet». Test deretter: logg inn som kunde A og prøv å åpne kunde B sitt prosjekt med ID-en.
Lærdom: å skjule noe på skjermen er ikke det samme som å beskytte det. Mer om dette i er vibe coding trygt?.
6. En lanseringsside med venteliste
Hvem bygger den: gründere som tester en idé før de bygger den.
Første prompt:
Bygg en landingsside for en app som hjelper lærere å planlegge timer og ta imot betalinger. Hovedoverskrift, undertekst, påmelding med e-post, tre fordeler, en seksjon om hvordan det fungerer, og en FAQ. Lagre påmeldingene i en database med dato, og la meg laste dem ned som CSV fra en privat side.
Hva gikk galt: innen noen dager fylte listen seg med søppelpåmeldinger fra roboter, og siden hadde ingen tittel eller beskrivelse, så delte lenker viste en tom forhåndsvisning.
Fiksprompt:
Legg til grunnleggende botbeskyttelse på påmeldingsskjemaet (et skjult honeypot-felt og en grense på 5 påmeldinger per IP-adresse i timen). Legg til sidetittel, metabeskrivelse og et bilde for deling i sosiale medier.
Lærdom: et offentlig skjema blir funnet. Se hvordan bygge en venteliste-side.
7. En quizapp for en lærer
Hvem bygger den: lærere og trenere som vil ha noe lettere enn et LMS.
Første prompt:
Bygg en quizapp for klassen min. Jeg lager quizer med flervalgsspørsmål og ett riktig svar per spørsmål. Elevene blir med med en kode og fornavnet sitt, svarer på spørsmålene og ser poengsummen sin til slutt. Jeg ser en resultattabell per quiz.
Hva gikk galt: de riktige svarene ble sendt til nettleseren sammen med spørsmålene, så en nysgjerrig elev kunne lese dem i sidekilden. Elevene kunne også sende inn på nytt til de fikk 100 %.
Fiksprompt:
Ikke send riktige svar til nettleseren. Sjekk svarene på serveren etter innsending. Tillat én innsending per elevnavn per quiz, og vis læreren hvis noen prøver igjen.
Lærdom: nettleseren tilhører brukeren. Alt der kan leses.
8. Et lite KI-verktøy
Hvem bygger det: markedsførere, skribenter og gründere som vil ha en fokusert KI-assistent.
Første prompt:
Bygg et verktøy som gjør en produktbeskrivelse om til fem innlegg i sosiale medier med ulik tone (vennlig, ekspert, lekent, kort, langt). Bruk et KI-API. Jeg limer inn beskrivelsen, velger plattform, og får innleggene med kopiknapper.
Hva gikk galt: den første versjonen kalte KI-tjenesten rett fra nettleseren med API-nøkkelen inne på siden, der alle kunne kopiere den og kjøre opp regningen.
Fiksprompt:
Flytt KI-kallet til serveren. Lagre API-nøkkelen som en hemmelighet, aldri i frontend-koden. Begrens hver besøkende til 20 generasjoner per dag.
Lærdom: nøkler hører hjemme i hemmeligheter på serveren. Se hvordan holde API-nøkler trygge og hvordan legge til KI-funksjoner i appen din.
9. Et arabisk og engelsk nettsted for en bedrift
Hvem bygger den: bedrifter i Golfregionen og den bredere arabiske verden som betjener to språk.
Første prompt:
Bygg et nettsted for interiørdesignselskapet mitt på arabisk og engelsk, med en språkbryter. Sider: hjem, tjenester, portefølje, om oss og kontakt. Arabisk skal være fullt høyre-til-venstre.
Hva gikk galt: den arabiske teksten var høyrejustert, men layouten var ikke speilvendt: piler pekte feil vei og menyen lå på feil side. Telefonnumre vistes også baklengs noen steder.
Fiksprompt:
På arabisk, speil hele layouten: sett sideretningen til høyre-til-venstre, legg menyen til høyre, snu retningsikoner, og behold telefonnumre og e-postadresser venstre-til-høyre inne i den arabiske teksten.
Lærdom: høyre-til-venstre er en layout, ikke en justering. Mythex håndterer arabisk og andre høyre-til-venstre-layouter, og du kan skrive prompter på arabisk direkte.
10. En tracker som blir en mobilapp
Hvem bygger den: trenere, treningssentre og lokalsamfunn hvis brukere lever på telefonene sine.
Første prompt:
Bygg en treningslogg for personlige treningsklienter. Hver klient logger inn, ser treningsplanen jeg har tildelt for uken, krysser av øvelser og registrerer vekter. Jeg ser hver klients fremgang i et diagram.
Hva gikk galt: webappen fungerte, men på telefoner var knappene for små til å trykke på midt i en økt, og diagrammet var uleselig.
Fiksprompt:
Design dette for bruk med én hånd på telefon: store trykkflater nederst på skjermen, én øvelse per skjerm med store Neste- og Ferdig-knapper, og et enkelt ukentlig fremgangsdiagram.
Lærdom: hvis folk skal bruke det på telefon, design for telefonen først. På Mythex Pro kan den publiserte appen deretter bli en Android-app for Google Play og en iPhone-app sendt til TestFlight; telefonappen åpner den publiserte appen, så hver publisering oppdaterer den. Se siden mobilappbygger.
Mønstrene bak eksemplene
På tvers av alle ti faller feilene i noen få grupper:
| Feil | Hvor det dukket opp | Hvordan fange det |
|---|---|---|
| Regel aldri sagt høyt | Budsjettmåned, lager under null | Skriv reglene inn i prompten |
| To personer samtidig | Dobbeltbooking i salongen | Test med to nettleservinduer |
| Skjult er ikke beskyttet | Kundeportal, quizsvar | Prøv en annen brukers ID; se sidekilden |
| Hemmeligheter i nettleseren | KI-verktøyets nøkkel | Spør KI-en hvor hver nøkkel ligger |
| Misbruk av offentlige skjemaer | Botpåmeldinger til venteliste | Legg til hastighetsgrenser før du deler |
| Telefonen som ettertanke | Menybilder, treningsknapper | Test på en ekte telefon på mobildata |
Ingen av disse krever at du leser kode. De krever at du tester som en nysgjerrig, litt fiendtlig bruker, og beskriver det du ser nøyaktig.
Prøv en selv
Velg eksemplet som ligner mest på ideen din, kopier første prompt og endre detaljene. Bruk deretter fiksprompten som en sjekkliste før du deler den. Vår prompt-jukseark for vibe coding har 30 flere, og hvordan bygge en app med vibe coding går gjennom ett prosjekt fra idé til publisert app. Når du er klar, start den i KI-appbyggeren, eller bla gjennom maler for et forsprang.
Spørsmål
Hva kan du bygge med vibe coding?
Webapper og nettsteder med noen få skjermer og klare regler fungerer best: trackere, bookingsider, interne verktøy, kundeportaler, landingssider, quizer, dashbord og små KI-verktøy. Store apper med kompliserte tilgangsregler, sanntidsfunksjoner eller strenge compliance-krav er mulig, men krever mer gjennomgang.
Er dette ekte vibe coding-eksempler?
De er sammensatte eksempler på apptypene folk oftest bygger med KI-appbyggere, med prompten som starter dem og problemene som typisk dukker opp. Promptene er ekte og kan kopieres; detaljene er generalisert og ikke hentet fra ett enkelt prosjekt.
Hva går oftest galt i vibe coding-apper?
Data som ikke lagres etter en oppdatering, brukere som kan se hverandres poster, layouter som ødelegges på telefoner, dobbeltbestillinger eller doble innsendinger, og hemmelige nøkler plassert i kode som kjører i nettleseren. Hvert av dem er enkelt å teste for når du vet at du må se etter det.
Kan du lage en mobilapp med vibe coding?
Du kan lage en mobilvennlig webapp med hvilken som helst bygger. På Mythex Pro kan en publisert app også bli en Android-app du kan laste opp til Google Play og en iPhone-app sendt til TestFlight, og hver publisering oppdaterer også telefonappen.
Kan en vibe coding-app tjene penger?
Ja, hvis den løser et reelt problem for folk som vil betale. Bookingverktøy, priskalkulatorer og kundeportaler for små bedrifter er vanlige eksempler. Før du tar betalt av noen, legg til ordentlig innlogging, test betalinger nøye og gå gjennom sikkerhetsgrunnlaget.