Bygg ett bokningssystem med AI: tider, kunder och det som faktiskt går sönder

Ett bokningssystem är en kalender med regler, inte en marknadsplats

"Bygg ett bokningssystem" är den vanligaste meningen folk skriver i en AI-appbyggare. Det de behöver är mindre: en lista med tjänster, ett rutnät med lediga tider, en kundpost och en regel att två personer inte kan ta samma tid.

NorthernGo ger dig redan skalet. Varje app får en Supabase-databas i PostgreSQL inom EU, inloggning med e-post och lösenord, och en PWA. Du beskriver salongen, mottagningen eller verkstaden i text, med röst eller som en skiss. Arkitekt, Byggare och Granskare skriver en HTML-fil i vanlig JavaScript och Tailwind. Koden är din. ZIP-export finns på Premium och Pro.

Vad det här inte är: ett sjukhussystem med flera enheter, eller en betalprodukt. Betalningar använder ditt eget Stripe-konto på Pro. Första versionen ska ta ett namn, en tjänst och en tid, och vägra en krock.

Vad första generationen gör fel

Dubbelbokning. Modellen ritar en snygg kalender och en Spara-knapp. Den kontrollerar inte, om du inte säger det, att tiden fortfarande är ledig mellan klicket och skrivningen. Två kunder i en långsam mobil tar samma 14:00. Regeln hör hemma i prompten och i ett test: öppna två flikar, boka samma tid, bekräfta att en misslyckas.

Tidszoner. En tid sparad som "14:00" utan tidszon är en lokal sträng. En kund som bokar från en annan region, eller en telefon som bytte till sommartid, visar fel timme. För en salong på en adress i Sverige: spara tider i Europe/Stockholm och skriv ut det på skärmen. Hitta inte på en världsklocka i version ett.

Betalningar. "Lägg till kassa" ger oftare en fejkad knapp än en dragning. Lämna pengarna utanför första prompten. Ta bokningen. Bekräfta med e-post. Lägg till Stripe när krockarna är borta.

Behörigheter. Personal och kunder är olika jobb. Den genererade appen har en inloggningstyp om du inte hittar på ett role-fält och sedan själv ser till att det gäller. En "Admin"-bricka är färg.

Steg 1: Namnge posterna

Skriv kollektionerna före färgerna.

• customers — namn, e-post, telefon, createdAt.
• services — namn, durationMinutes, price (ett tal du visar, inte en dragning).
• slots — serviceId, startsAt (ISO-sträng med tidszon), status (free | held | booked), customerId.

Säg "e-post är unik på customers" och "en slot får ha högst ett customerId". De två meningarna stoppar det mesta av röran.

Steg 2: Sätt inloggning framför bokningen

En publik katalog över tjänster kan vara öppen. Att skapa en bokning ska kräva ett konto, så att du har någon att mejla och någon som kan radera sig själv. Varje app med inloggning måste ha en fungerande radera-konto-väg — GDPR artikel 17. Skriv in det i första prompten. Plattformen lägger tillbaka knappen om en senare ändring tar bort den.

Personal som sköter rutnätet ska använda en separat inloggning du skapar för hand. Det finns inget inbjudnings-API och inget magiskt "bara @salongen.se".

Steg 3: Generera, angrip sedan tiden

Be om de tre skärmarna: lista med tjänster, veckorutnät, mina bokningar. Generera lokalt när du itererar på layout — obegränsat på alla planer — och lägg en molngenerering när datamodellen är fel.

Öppna sedan två webbläsare. Boka 14:00 i båda. Om båda lyckas är appen inte ett bokningssystem än. Lägg in en explicit kontroll: get('slots'), hitta id:t, vägra om status inte är free, sedan save med booked. Det finns inget transaktions-API. Kontroll-sedan-skriv kan fortfarande kappas. För en salong med en stol är det oftast acceptabelt. För tjugo parallella stolar är det inte det — säg det innan du säljer.

Steg 4: Bekräfta med e-post, inte med hopp

window.NorthernGo.sendEmail(to, subject, html) skickar ett transaktionsmejl. Anropa det efter en lyckad sparning, inte före. Ta med tiden i Europe/Stockholm, tjänstens namn och en mening om att avbokning sker i appen, inte genom att svara.

Lägg inte andra kunders e-post i sidkällan. get('customers') är kopplat till den inloggade; bygg inte en adminvy "alla bokningar i dag" som dumpar alla på en publik URL.

Steg 5: Bestäm vad version två får vara

Version två kan vara Stripe-deposition, SMS-påminnelser (ingen inbyggd SDK — du skulle webhooka ut) eller ett Fortnox-rör på Pro. Version två ska inte vara "också en marknadsplats för tio salonger". Det är en annan produkt.

Exportera koden på Premium eller Pro innan du är beroende av live-adressen. Inlåsningsguiden är utgångsplanen. Läs den genererade filen efter innerHTML och allt som ser ut som en nyckel innan första riktiga kunden.

Skrivningen som faktiskt tar luckan

Klistra in den här formen i prompten, eller i filen efter första generationen, så att agenterna inte hittar på en andra databas.

async function bokaTid(tidId, kundEpost) {
  const tider = (await window.NorthernGoDB.get('slots')) || [];
  const lucka = tider.find((s) => s.id === tidId);
  if (!lucka || lucka.status !== 'free') {
    throw new Error('Den tiden är inte ledig längre.');
  }
  await window.NorthernGoDB.save('slots', {
    ...lucka,
    status: 'booked',
    customerId: kundEpost,
    bookedAt: new Date().toISOString()
  });
  await window.NorthernGo.sendEmail(
    kundEpost,
    'Din bokning är bekräftad',
    '<p>Vi bokade dig ' + lucka.startsAt + '. Avboka i appen.</p>'
  );
}

Tre saker i den funktionen gör jobbet den snygga kalendern hoppar över. Den läser luckan på nytt. Den vägrar allt som inte är ledigt. Den mejlar bara efter sparningen. Den kan fortfarande inte låsa raden. Två telefoner som båda klarade kollen kommer båda att skriva booked. Inaktivera knappen efter första klicket. För en salong med en stol i Lycksele är racet sällsynt. För ett släpp på fyrtio konsertplatser är det produkten, och det här API:t är fel verktyg.

Spara startsAt med offset (2026-09-03T08:00:00+02:00) och visa Europe/Stockholm på skärmen. En stuga i Ammarnäs bokad från Berlin glider annars två timmar. Modeller älskar datumformatering utan språkkod. Läs den delen av filen.

De sista tjugo procenten är den här funktionen, testet i två webbläsare, knappen för att radera kontot, och beslutet att hålla pengarna borta tills krockarna är borta. De första åttio är agenterna. Ett bokningssystem som struntar i uppdelningen ser färdigt ut på måndag och dubbelbokar på fredag.

Ett bokningssystem är det snabbaste publika användningsområdet den här byggaren har. Det är också det snabbaste sättet att lära sig att en kalender som ser färdig ut inte är ett färdigt system. En första prompt som namnger kunder, tjänster, tider, inloggning, radera-konto och sendEmail slår en prompt som bara säger bokningssystem. Lägg en molngenerering på det kontraktet. Iterera lokalt på färgerna. Angrip sedan luckan i två webbläsare innan du ger någon adressen. En salong med en stol i Lycksele kan leva med den kvarvarande racet. Ett släpp med fyrtio parallella stolar kan det inte. Säg den skillnaden högt innan första kunden. Om prompten aldrig nämnde deleteAccount, sendEmail och en status ledig-eller-bokad kommer första generationen att hitta på en kalender som skriver till localStorage och gratulerar dig. Det är en demo. Ett bokningssystem är funktionen ovan, plus testet i två webbläsare, plus en kund som kan radera sig själv. Publicera på subdomänen och prova i en telefon i butiken. En PWA som bara fungerar i editorn är fortfarande inte ett bokningssystem. Gratisplanen ger fem molngenereringar och obegränsat lokalt. Lägg det lokala på rutnätet. Lägg en molngenerering på kontraktet. Slösa inte månaden på att polera en kalender som fortfarande skriver till localStorage. De sista tjugo procenten är det arbetet. Agenterna tar dig inte dit. Du gör det, eller en utvecklare som kan läsa en HTML-fil.