Serviced-apartment access & pricing platform
The first system built and sold through my own company, now taking real guests. Five serviced apartments in one building, run end to end: a staff dashboard, a separate guest check-in site, door codes that exist only during the stay, cleaner alerts on checkout, late-checkout requests, pricing from local event demand, and profit reported per operating company.
How the secrets are handled
- Every door code is encrypted with AES-256-GCM before it reaches the database. A stolen database dump contains ciphertext and nothing else.
- Guest check-in links are HMAC-signed tokens carrying the booking and an expiry — not guessable, and not editable to point at another booking.
- Staff passwords are scrypt-hashed with a per-user salt; webhooks are rejected unless the signature matches the raw body.
- Neither key is ever sent to a browser. The guest page asks the server what it is allowed to see and gets back a code or nothing.
Two decisions that come from operations, not code
Codes are issued at booking confirmation, not at check-in. The PIN is written to the lock days ahead and lives in the lock’s own memory, so a broadband fault on arrival day cannot lock a guest out of the building at eleven at night.
Rotation writes the new code before retiring the old one. If the lock is unreachable the old code keeps working and the failure is logged — the opposite order would leave a cleaner standing outside a flat they can’t enter.
Built before the hardware existed
The lock provider sits behind an interface with a mock implementation, so every path — issue, reveal, revoke at checkout, rotate — runs for real against a simulated lock. One environment variable swaps the mock for the live provider when locks are installed. No application code changes.
Pricing from local demand
- Three event sources refreshed daily and merged into one table — a venue what’s-on page, a ticketing API and a fixtures feed — because the trade shows that actually drive midweek demand never appear in ticketing APIs.
- The scraper runs once a day, identifies itself with a real contact address, uses conditional requests so an unchanged page costs a few bytes, takes facts only, and stops on a 403 rather than retrying — a bad fetch leaves yesterday’s events in place rather than emptying the calendar.
- Long-running exhibitions are capped in the weighting: a three-month immersive experience is background footfall, not a spike.
- The demand weightings are documented as informed guesses to be replaced by the client’s own occupancy data after a season, rather than presented as fact.
What the guest gets
- A personal stay page: wifi for their apartment with tap-to-copy, directions, check-in steps, photos, the house manual, emergency contacts, and local exhibition and concert dates that fall inside their stay.
- Door and entrance codes that appear at 15:00 on arrival and vanish at 10:00 on departure — on UK time, correct across the clock change, which is exactly the night a naive timestamp gets wrong.
- An arrival message sent automatically from the property’s own domain under the building’s name, verified for inbox delivery, with replies routed back for handling.
- Late checkout from their own page. On approval the checkout time and the door code both move automatically, and the fee is collected through whichever platform they booked on.
Turnaround without phone calls
Guest checkout starts the chain. The cleaner is alerted the moment a flat is free, the guest’s code closes at the same time, and the unit goes back on sale. Cleaners work from a personal link with nothing to remember, and upload photos for review.
Revenue side
- Launch rates set from a local competitor pricing analysis, with separate bands for studios and two-bedroom apartments, loaded twelve months ahead.
- A built-in prompt to move to demand-based pricing once enough stays have completed — rather than pretending to have data on day one.
- Occupancy, revenue and profit reported split by operating company, because the apartments are let through more than one business and the books have to separate cleanly.
Run as a client engagement
Scoped from a setup questionnaire, delivered under a signed service agreement, and closed out with a delivery record listing all 24 items built and every item still owed by the client — platform accounts, photographs, lock hardware — with what each one blocked.
What’s written down as not done
- Two-factor for staff, and secrets moved out of environment files into a managed store.
- Automated encrypted backups with one tested restore — untested is not a backup.
- A data processing agreement with the client, ICO registration, and a retention job deleting guest personal data on a schedule.
- The lock adapter swaps in with one setting once hardware is fitted; a day is budgeted for field issues rather than assuming the first install goes clean.