Jag har nyligen byggt en webbplats åt en massageterapeut som driver sin egen verksamhet. Det är den typen av projekt där kraven är lätta att formulera, men där det är lätt att göra fel om man försöker lösa allt på egen hand: en snygg startsida, en onlinebokning som faktiskt fungerar och ett sätt för ägaren att hantera sitt schema och sina behandlingar utan att behöva ringa mig varje gång något ändras.

Så här valde vi att använda Hapio, och varför det fungerade bra.

Utgångspunkten

Min kund hade redan en Facebook-sida och tog emot bokningar via Messenger. Det fungerar – tills det inte gör det längre. Dubbelbokningar, glömda tider, att manuellt behöva svara på samma frågor om priser och tillgänglighet. Hon ville ha en egen webbplats där kunderna kunde boka direkt, och där hon själv kunde stänga vissa dagar, justera öppettiderna och lägga till nya behandlingar.

Det viktiga är att hon är massageterapeut, inte systemadministratör. Allt vi bygger måste vara begripligt för någon som inte tänker i termer av databaser och API:er.

Varför inte bygga bokningssystemet själva?

I skulle kunna har utvecklat ett skräddarsytt bokningssystem. Laravel, ett bookings tabell, logik för lediga tider, hantering av konflikter, väntetider mellan behandlingar, hantering av stängningsdagar, sommarlov…

Men det är precis den typen av kod som ser enkel ut på en whiteboard men som i praktiken leder till sex månaders arbete med specialfall. En enda resurs (en terapeut), återkommande öppettider med undantag, buffertar före och efter varje behandling, olika behandlingstider – det är ingen raketvetenskap, men det bliren hel delkod som inte tillför något unikt värde för just det här projektet.

Det sköter Hapio. Vi har ett färdigt API för tillgänglighet, bokningar, tjänster och schemaläggning. Jag kunde fokusera på det projektet egentligen handlade om: en snygg webbplats och en bokningsprocess som känns somderas egen, inte som ett generiskt bokningssystem.

Den arkitektur vi fastnade för

Vi har utvecklat en enkel Laravel-app som fungerar som ett skal runt Hapio. Tänk ”frontend + integrationslager”, inte ”ett komplett bokningssystem”.

Hapio ansvarar för:

• Bokningar (skapa, hämta, avboka)
• Tjänster/behandlingar (namn, varaktighet, pris, väntetider)
• Återkommande öppettider (mån–sön)
• Dagar då verksamheten är stängd (helgdagar, sjukdagar eller liknande)
• Beräkning av tillgängliga platser utifrån alla ovanstående faktorer

Laravel ansvarar för:

• Landningssidan och bokningsgränssnittet (Livewire)
• Administratörspanel för schema, tjänster och bokningsöversikt
• E-post (bekräftelse, påminnelse, avbokning – till både kunden och ägaren)
• Säkra avbokningslänkar (HMAC-signerade, så att kunderna inte kan gissa sig in i någon annans bokning)
• Cachelagring av lediga platser (Redis)
• Hantering av webhooks när Hapio-data ändras

Laravel-databasen innehåller i princip endast administratörsanvändare, sessioner och köjobb. Inga bokningsuppgifter lagras lokalt. Hapio är den enda tillförlitliga källan.

Det känns lagom för ett företag av den här storleken. En liten lokal databas, en Redis-instans – inget att underhålla som inte är nödvändigt.

Bokningsprocessen

Kunden går igenom fyra steg: välj behandling → välj tid → fyll i uppgifter → klart.

Behandlingarna hämtas från Hapio när sidan laddas. Tiderna hämtas per vecka – vi cachelagrar dem intensivt i Redis eftersom det är den data som har högst trafik. En veckovy där kunden kan bläddra upp till tolv veckor framåt.

När bokningen har bekräftats:

1. Bokningen skapas i Hapio
2. Kunduppgifter (namn, telefonnummer, e-postadress, valfritt meddelande) sparas som metadata i bokningen
3. En avbokningslänk genereras (HMAC-signerad med en hemlig nyckel som vi kontrollerar)
4. Ett e-postmeddelande skickas till kunden och ägaren

Avbokning sker via den signerade länken – ingen inloggning krävs. Vi har en 24-timmarsregel: du kan inte boka eller avboka med kortare varsel än så. Regeln tillämpas i vår kod vid läsningstillfället, inte i cachen, så den fungerar konsekvent även om cachen ännu inte har ogiltigförklarats.

Administratörspanelen

Ägaren loggar in och har fyra flikar:

• Bokningar– kommande och tidigare, med möjlighet att avboka
• Schema– klicka på en dag i kalendern för att stänga eller öppna den
• Öppettider– det återkommande veckoschemat, dag för dag
• Tjänster– lägg till, redigera, inaktivera behandlingar

Allt sker via Hapio-API:et. Administrationspanelen är i princip ett snyggt gränssnitt som bygger på deras datamodell. När hon ändrar öppettiderna eller stänger en dag skickar Hapio en webhook, vi tömmer cachen och bygger upp tidsluckorna på nytt i bakgrunden.

Det krävdes en del arbete för att få webhook-flödet att fungera tillförlitligt – signaturverifiering, idempotens, fallback till fullständig cache-rensning om något går fel – men när det väl var på plats var det väl värt mödan. Lediga tider uppdateras snabbt utan att vi behöver göra förfrågningar till API:et.

Vad som fungerade bra

Åtskillnad mellan olika ansvarsområden.Vi behöver inte sköta bokningslogiken. Hapio hanterar konflikter, buffertider och schemaläggning. Vi sköter användarupplevelsen och det som är specifikt för webbplatsen.

Webhooks + cache.Lediga tider sparas i cachen i 24 timmar. När något ändras i Hapio (ny bokning, ändring i schemat, ny tjänst) och en händelse registreras, ogiltigförklarar vi den aktuella cachen och laddar om den. Kunderna ser uppdaterade tider utan att vi behöver hämta all information från API:et vid varje sidvisning.

Metadata om bokningar.Kunduppgifter lagras som metadata i Hapio-bokningen. Vi behöver ingen separat kundtabell. För ett enmansföretag räcker det.

Länkar för avbokning.HMAC-signerade länkar i bekräftelse- och påminnelsemejl. Kunden behöver varken logga in eller komma ihåg ett bokningsnummer. Vi verifierar token på serversidan innan avbokningen godkänns.

Administration utan tekniskt krångel.Ägaren kan själv hantera sitt schema och sina tjänster. Jag behöver inte vara inblandad när hon vill stänga en dag eller lägga till en ny behandling.

Saker vi var tvungna att fundera på

SDK och felhantering.Vi använder Hapios PHP-SDK som ett sökvägsberoende. SDK:t genererar ibland PHP-varningar som överskuggar de egentliga felmeddelandena – vi har kapslat in anropen och undertryckt varningarna så att API-felen faktiskt kommer fram.

24-timmarsregeln.Affärsregeln ”minst 24 timmar före bokning/avbokning” tillämpas i vår kod vid läsning, inte i Hapio. Det innebär att cachen kan innehålla tidsluckor som inte visas för kunden – vi filtrerar bort dem när vi returnerar data. Enkelt och förutsägbart.

En resurs, en plats.Konfigurationen pekar på en enda plats och resurs (terapeuten). Om verksamheten skulle växa till att omfatta flera terapeuter eller platser skulle vi behöva se över saker och ting, men för den nuvarande uppsättningen fungerar det perfekt.

Sammanfattning

För en liten massageklinik där ägaren måste sköta allt själv var Hapio det rätta valet. Vi skapade inte ett bokningssystem – vi byggde en webbplats och ett integrationslager som gör Hapio tillgängligt på ett sätt som passar verksamheten.

Laravel + Livewire för användargränssnitt och e-post. Hapio för all bokningslogik. Redis för cache. Webhooks för att hålla cachen synkroniserad.

Tack vare Hapio – och med hjälp av AI längs vägen – tog det ungefär en helg att bygga upp hela webbplatsen från grunden till något som hon faktiskt kunde börja använda i sin verksamhet.

Det är inte den mest komplexa arkitekturen jag har skapat, men den är en av dem som känns mest välavvägd för projektet. Och det är ju det man vill ha.

Utkast. Hänvisningar till specifika platser, lägen eller personer har avsiktligt utelämnats.