Layered: a site that sells the course and checks the guest in
A website for an education brand that connects course sales, capacity, payments, invoicing and tickets. The attendee picks a date, pays and receives both the document and the ticket. The organiser has an overview of attendees without retyping anything by hand.
Courses were sold without a website
Layered had no website at all. Courses were arranged over social media and e-mail, payments were matched by hand and invoices written one at a time. On the day, attendance was ticked off a printed list.
So we started from scratch: the brand needed its first website and at the same time the whole line from selling a seat to checking the attendee in at the door.
Six parts that follow on from each other
A site on Astro (SSR)
A server-rendered website whose content the client manages herself in Directus.
Course sales
Pick a date, pay by card through Stripe Checkout or by bank transfer, with the price calculated on the server.
Capacity in real time
The last seat cannot be sold twice. The booking runs in a database transaction and an unfinished payment holds the seat for a limited time.
Invoicing through Fakturoid
A proforma with a QR payment is created on its own; once paid, Fakturoid issues the final document. Organisational confirmations go out through Resend under the Layered brand.
Content in Directus
Courses, dates, lecturers and copy in one place, with no developer involved.
Tickets through Walio
A date linked to an event in Walio issues a wallet ticket once payment clears. The system makes sure a ticket is never issued twice.
From the course to the booking
At every step you can see what the attendee does and what the system handles for them.
Course listing and date detail
The landing page orders courses by the nearest date. The detail holds the programme, the lecturer, the price and the number of seats left. The client manages the content in Directus; no deployment is needed.
The main event page
The high point of the year is a three-day event with an international lecturer. It has its own page with the artwork, the venue and the language, so it also works as a standalone link in a campaign.
A programme split by day
Each day has its own block: who it is for, what is covered and at what time. Before buying, the attendee knows whether they want only the lecture or the hands-on part too.
Booking and payment in three steps
The attendee picks a date, fills in their details with consent to processing and pays by card or transfer. The price is calculated on the server, the seat is held during payment and once paid the document and the ticket go out.
From the payment to the scanner at the door
Once paid, the site calls the Walio API, which issues a QR ticket into Apple or Google Wallet and e-mails it to the attendee. At the venue the organiser scans it. The document is created in Fakturoid: first a proforma with a QR payment, then the final invoice once paid.
Tickets are issued by Walio, our own product. The service fee is paid by the buyer, so Layered neither loses nor earns on tickets. Card and bank transfer both work; Fakturoid matches the incoming payment and sends us a webhook.
Walio case studyFour stages, each with an outcome
Brief and structure
We went through what the client sells and how she records attendees today. That produced the site structure and the data model.
Interface design
First we tuned the purchase path and the course page, and only then the rest of the site.
Development and integrations
The site on Astro SSR, content and bookings in one Postgres. Payments through Stripe, documents in Fakturoid, tickets through the Walio API.
Launch and operation
The site is live and the client manages the content. The design will still change; the functionality is finished.
Two decisions that save manual work
Payments through Stripe, not our own form
Card details never pass through our site at all. The client is not responsible for storing them and we do not deal with payment certifications. The cost is that the payment page is not ours.
The last seat cannot be sold twice
Capacity is held by a database transaction and an unfinished payment blocks the seat for a limited time. Better that a customer sees sold out than two people turning up for one seat and the client sorting it out by phone.
Site, content and bookings
Content and bookings share a single database in Neon. The client changes copy and dates in Directus without a deployment.
The scope of the solution
I came saying I wanted to sell courses online. I left with a website that also handles the invoices and the tickets for me. For the first time at an event I did not have to tick anything off a paper list.
Working on something similar?
Tell us what you do by hand today: payments, invoices, attendee records. We reply within two business days.
What else we built
Walio: a loyalty system for businessesA card in the wallet, a terminal for staff and a portal with reporting.
Branuál: a brand manual as a website, not a PDFPages, blocks and an asset library with publishing. Our own product.
SinClinic+: a clinic website the clinic runs itselfThe clinic edits procedures, doctors and the price list in Keystatic.