A private concierge firm's public site, and the back office behind it: requests come in, the desk sources partners, prices offers and tracks bookings, with a written history against every one.
The brief was a homepage. What the business actually needed was somewhere for the work to live once a request arrived, so that is what it became.
This started as a homepage redesign for a private concierge firm. The site needed to look like the service it was selling: unhurried, discreet, and clearly not a booking engine.
The redesign surfaced the real problem. A concierge desk lives or dies on what happens after a request arrives, and that part was happening in messages and spreadsheets. So the work widened into the system behind the site: sourcing suppliers, putting a request to them without revealing who is asking, pricing the result, turning it into an offer, and keeping the history of how it got there.
The two halves are deliberately different products with different rules. The public side is editorial and fast. The desk side is careful, permissioned, and structurally incapable of leaking what suppliers charge.
Offers, bookings and companies become records rather than messages.
OpenGetting supplier material into structured, priced listings without retyping it.
OpenThe admin subdomain, the access review, and the checks before it went out.
Live counts, a priority queue, tasks, messages and the history behind each one.
The engineering capabilities this engagement demonstrates, beyond the screens.
The front door
For this kind of business the website is the first impression and the qualifying step at once. It has to establish that this is not a booking service, then get enough detail that the desk can act on the request.
Core engineering challenge
Making an editorial, image-led site fast and coherent, while quietly doing the commercial job of turning a visitor into a written brief.
The front door
An editorial front door that captures the request before it wanders off to a messaging app.
For this kind of business the website is the first impression and the qualifying step at once. It has to establish that this is not a booking service, then get enough detail that the desk can act on the request.
Core engineering challenge
Making an editorial, image-led site fast and coherent, while quietly doing the commercial job of turning a visitor into a written brief.
Live inventory
The published side of a much richer internal record.
A concierge sells reach, and reach has to be demonstrable before someone will make a request. This is the surface that does that without giving the trade away.
Core engineering challenge
Publishing genuinely useful detail while guaranteeing that supplier terms, cost prices and sourcing relationships cannot appear, no matter which endpoint is called or which page is added next.
The season
The dated events the year is planned around, one page per edition.
Demand in this business is seasonal and event-shaped. Giving each edition its own page turns the calendar from a list into something the desk can point a client at.
Core engineering challenge
A content type that has to work as both an editorial page and a commercial anchor, without going stale when an edition passes.
The supply side
Put a request to named suppliers, and let them quote without ever seeing the client.
Sourcing is the actual work of a concierge desk. Doing it in a portal rather than in a mailbox means the responses are comparable, attributable and kept.
Core engineering challenge
Two audiences inside one application with genuinely opposed interests, where a single over-broad endpoint would leak the client to the supplier or one supplier's price to another.
The brief
The point where a visitor becomes a piece of work with a history.
Everything downstream depends on the request being captured as a durable record rather than a message someone has to remember to act on.
Core engineering challenge
Asking a discerning client for enough detail to act on, without making the form feel like an application.
The public surface: the story of the service, what the desk can reach, the offers the desk currently has published, and a request flow that gets a real brief written down. It is built to read like a magazine rather than a marketplace, because the proposition is access and judgement, not inventory.
The public inventory: what the desk currently has access to, presented for a client rather than for a supplier. What a visitor sees here is a deliberately reduced view of the internal record, and the reduction happens in the data layer rather than in the template, so a field that suppliers see can never arrive on a public page by accident.
The fixed points in the calendar that this kind of client plans around, each edition with a page of its own so it can be linked, described and sold against rather than listed as a line of text.
The other half of the marketplace. The desk can put a live request out to specific partners and collect what comes back, and partners get their own portal to respond in. A partner sees the requirement; a partner never sees who is asking, and never sees what another partner quoted.
The request flow, and the record it creates. A submitted request is not a notification email: it is the beginning of a thread the desk works, with sourcing, offers, bookings and messages hanging off it and a written history of how it progressed.
Hiding a page is not access control. Every rule is enforced where the data is served rather than where it is rendered, and there is a script that walks the endpoints and asserts it, so the guarantee is checked rather than believed.
The public side is assembled from a separate, reduced shape rather than a full record with the sensitive fields filtered out in the template. A field that never enters the public shape cannot be leaked by a new page, a careless serialiser or a debugging endpoint. It is checked in production rather than assumed.
The back office lives on its own subdomain, served by an internal rewrite instead of a redirect. Visitors never see admin paths appear in the address bar, and the two audiences never share a URL space.
Twenty schema migrations applied by hand, each written so that running it a second time is harmless and so that not having run it yet is detectable. That is what makes a hand-applied schema safe to touch under time pressure.
Supplier material arrives as PDFs and photographs, and turning that into a structured, priced listing is genuinely tedious. So that step is assisted, including scans that need reading. The line is drawn where it should be: the concierge chat on the site answers only from what has actually been published, and declines rather than improvising, because a confident invention is worse than no answer in a business built on trust.
The desk arranges access through partner suppliers in hospitality, travel and events. Those partners are the network the platform coordinates on the client's behalf, not services we built or operate.
A homepage redesign that turned into the operating system behind the desk, delivered in a few intense weeks and now live.
The brief was a homepage. What the business actually needed was somewhere for the work to live once a request arrived, so that is what it became.
