Six connected modules built on a live PHP booking platform in two months, and the three working rules I am keeping for every project after it.
For the past two months I have been working almost full time in one codebase: a booking platform for holiday accommodation, written in PHP on its own MVC setup. Not a greenfield project, but a running system that handles money and serves customers every day. You build differently in there than in an empty folder.
The result sits in the system's own changelog: 269 numbered changes, from version 1.0.0 to 1.0.271, between mid June and the end of July. That sounds like a lot of small things, and partly it was. But six connected modules came out of it that are worth writing down.
An interactive booking map with live availability
The old booking form was a list of dropdowns. Visitors had to guess where a spot was and whether their dates were free. The new version is a floor plan: you see the location from above, with numbered markers per spot, and for any date each marker turns green, red or amber.
There is more underneath than it looks. A spot can be linked to a main spot, so the two are only bookable together. Each location has a maximum number of people, and the remaining spots close automatically once that maximum is reached. Prices shown in the calendar are the prices after discount, not a bare day rate that quietly changes later in the form.
The map runs as embed code on external sites, in four languages, without a framework. Vanilla JavaScript, because the widget lands on other people's sites and must not break anything there.
A task board where AI does the groundwork
This is the project I learned the most from. Clients and staff submit a request on a Kanban board. From there a chain runs. First a report is written automatically that works the request up into a concrete proposal. Then comes a checklist of test points, and finally a visual mockup based on the current theme and the real page layout of the system.
The last step is a button that lets the developer actually have the request built, using the report, the mockup, all attachments and the conversation underneath. There is a note block alongside it that works as a conversation between requester and developer, with permissions per role, and email on a reply.
What it buys you: the vague request "could the calendar be a bit clearer" becomes a worked out proposal with a picture within minutes, which the requester can accept or reject. That saves a lot of back and forth.
Calendar connectors that never overwrite anything quietly
Location owners track their occupancy in different places. Some in a calendar that can hand out an iCal address, others in a Google Sheet with coloured cells. Both are connected now.
For the spreadsheets, AI was the obvious choice: a sheet with merged cells and colour codes has no fixed format, so a model reads across it, pulls out the occupied periods and gives each line a confidence score. What comes out does not go straight into the calendar. Everything lands on a worklist where a person approves or ignores it.
That last part is deliberate. A connector that adjusts reservations on its own is a connector that will one day quietly push a booking aside. The approval step costs ten seconds per change and prevents that conversation entirely.
A partner portal with a monthly report that writes itself
Location owners have their own environment now, with their own two-factor login, separate from the booking system. Inside: a yearly dashboard, their own calendar, and the option to block off periods themselves.
On top of that comes a monthly report as a PDF. It combines booking figures from the system with visitor figures from Google Analytics, pulled for every language path of the same page. It includes an AI assessment of the owner's own location photos, with concrete points on what could be better. The report exists in two versions: one for the owner, and a fuller internal one.
Newsletter and shared mailbox in house
The newsletter largely assembles itself from what is actually available, last minute offers included. It translates into the recipients' languages, sends in batches in the background, and tracks who opens, clicks and unsubscribes.
That last part turned out to matter more than expected. The mail provider only keeps its logs briefly, so without our own record, "when did this person last open something" is unanswerable six months later. There is a dedicated table for it now.
Next to it sits a shared mailbox with rules and a queue, replacing a separate ticket system. Fewer subscriptions, and customer data stays in one place.
Pricing and commission with a trail back
The least visible one, and probably the most important. Prices now have seasons, five kinds of discount, and changes you schedule ahead on a date. Every change stores a snapshot along with who made it. Pound prices follow the ECB daily rate plus a configurable margin.
Commission comes in three variants, including a tier per person. More importantly, the basis for it is now written down explicitly, with one shared calculation instead of four places that each calculated it slightly differently.
What I am taking from this
Three things I will do the same way on every project after this.
An approval step is cheaper than a rollback. Anywhere a connector or an AI suggests something, it only suggests. A person presses accept.
Payment statuses only move up. No automatic flow may push an invoice back to unpaid. That is a hard rule in the code now, not an agreement.
A changelog inside the system works. Not in a separate document, but on a page in the admin, in the user's own language. Everyone sees what changed without having to ask.
Read more
- What AI can really do for your business - practical AI without the hype
- RPA or AI? An honest choice for your process - when to pick software robots, when to pick AI
- See all completed projects - web platforms and automation solutions
Bert