// services
Custom booking and marketplace systems built around your business.
Off-the-shelf booking tools work until your process stops fitting them: owners who confirm manually, several brands, special pricing rules, partners with their own accounts. Then the workarounds start to cost more than the tool.
I design and build booking and marketplace systems around how your business actually works — availability, reservations, payments, roles and admin — with the transactional logic that stops two customers from booking the same slot.
01 // fit
This service is for you if…
- your booking flow includes manual steps, such as an owner or manager confirming the reservation;
- you run several brands or cities and do not want a separate system for each one;
- partners, owners or specialists need their own accounts and admin views;
- payments need authorization, capture or refunds tied to the booking status;
- double bookings or availability mistakes already happen;
- a generic SaaS tool cannot model your pricing or business rules.
02 // scope
Scope of work
- scope/01
Availability and calendars
Inventory, schedules and availability rules for vehicles, rooms, specialists or any other bookable resource.
- scope/02
Reservation logic
Holds, confirmations and cancellations with locking, so the same slot cannot be sold twice.
- scope/03
Payments
Authorization, capture and status handling that follow the booking lifecycle, with idempotent requests.
- scope/04
User areas and roles
Accounts for customers, partners and managers, each with the views and permissions they need.
- scope/05
Admin panel
A back office for bookings, partners and content — often built with Quasar as a PWA.
- scope/06
Multi-brand and multi-city
One backend serving several storefronts, so a new brand or city is configuration rather than a new project.
03 // diagram
How a booking stays safe from search to confirmation
Two customers try to book the same dates at the same moment. The first request locks the slot; the second is refused before any money moves. That lock is the part generic tools most often get wrong.
- 01Searchdates and location
- 02Availabilitycheck free slots
- 03Reservation lockhold the slot
- 04Paymentauthorize & capture
- 05Confirmationbooking confirmed
04 // pipeline.yml
How the work goes
- ~1 wkdiscovery:process
Discovery
How bookings, payments and confirmations work today — including the manual steps and the exceptions.
→ process map - ~1 wkplan:data-model
Plan
Data model, booking states, payment flow and roles, with milestones and an estimate.
→ architecture & estimate - weeksbuild:iterate
Development
The core booking flow first, then accounts, admin and integrations — demoed weekly on staging.
→ working platform - launchdeploy:release
Release
Launch with real data, monitoring and a rollback path.
→ live bookings - ongoingsupport:ongoing
Support
New cities, brands, partners and features as the business grows.
→ growing platform
05 // outcomes
What you can expect
- A booking flow that matches how your business actually works.
- Protection against double bookings in the database, not only in the interface.
- Payments tied to the booking status, with clear handling of failures and retries.
- An admin panel your team can run day-to-day operations from.
- An architecture where a new brand or city is configuration, not a new project.
06 // stack
Technology involved
A typical setup for a booking platform; the payment provider and integrations are chosen with you.
07 // evidence
Where I have done this before
The closest example is my own car rental platform in Thailand — still in progress and already taking bookings.
- A transactional booking and payment flow: authorization, owner confirmation, payment capture, idempotency and double-booking protection.
- Two brands — thailandrentalcars.com and phuketcarrentals.com — on one shared Node.js (Express) backend with a Quasar admin (PWA).
- 5 bookings so far.
08 // faq
Questions clients ask first
Why not use a ready-made booking SaaS?
If a SaaS tool fits your process, it is usually the cheaper option — and I will tell you so. A custom system makes sense when you have manual confirmations, several brands, partner accounts or pricing rules the tool cannot model.
How do you prevent double bookings?
Availability is checked and the slot is locked inside a database transaction before payment starts. A second request for the same slot is refused instead of creating a conflict that someone has to sort out by hand.
Which payment provider will you use?
The payment flow is built around authorization, capture and refunds with idempotent requests. The provider itself is chosen with you, based on your country, currency and business model.
Can one system serve several brands or cities?
Yes — that is how the Thailand rental platform works: one backend and admin, two independent storefronts. Adding a city is configuration rather than a new project.
Can partners manage their own listings?
Yes. Roles and partner accounts are part of the data model from the start, so each partner sees and edits only their own inventory and bookings.
We already have a booking system. Where do we start?
With an audit of the current booking flow and data. Sometimes the existing system can be fixed and extended; sometimes the booking core needs to be rebuilt while everything else stays.
09 // related
Related services
- nuxt.config.tsNuxt & Vue developmentSSR, SEO, performance, API integrations and complex interfaces — Vue and Nuxt applications built to run in production, not just in a demo.Nuxt & Vue development for production products →
- takeover.shWeb application takeoverYour web application lost its developer or team. I audit everything — code, servers, access, data, integrations — and take responsibility for it.Taking over a web application without an owner →
git push --message
Have a booking process a generic tool cannot handle?
Describe how a booking works in your business today, including the manual steps. I reply within one working day with questions or a first estimate.