The program nobody at the hotel could explain
Felix Hellström
Founder, Klarhimmel

A hotel in Stockholm depended on one program for guest door codes. It had been written years earlier, and the developer was about to retire. The owner needed to keep that daily job working and make the system understandable to someone else.
What the owner needed
Staff needed to work without depending on one screen on one computer. The owner needed a replacement that could be maintained, with clear operating notes and a safe way to transition from the existing setup.
Read before changing anything
Research and preparation ran from April to September 2026, around the owner’s calendar. I read the lock-system documentation and checked it against the installed system. Understanding the existing system gave us a basis for choosing what to replace and what to keep available during the transition.
Build beside the existing system
The build itself took four days, 8–11 September. The existing program stayed available while we built its replacement. We checked that the replacement matched the booking system’s arrival information before staff relied on it.
What was delivered
The delivery was a phone-first web app for authorized staff, with key information and arrivals in one place, door-code creation within an allowed set of keys, a journal of writes made through the replacement, and operating notes with a documented handover.
After the initial build, the work continued with production checks, write safeguards and operating notes for the hotel.
What changed in the daily job
The owner makes door codes from a phone. Arrivals can be checked alongside the relevant key information. The replacement has been in use since September 2026; the old setup remained available while the owner gained confidence in it.
The scope of this phase
This phase covered the staff tool, its booking and key integration, controlled door-code writes and the handover. Fully automatic check-in and retiring the remaining legacy setup are separate phases.
Leave a record the owner keeps
The system and operating notes belong with the hotel so another developer has a starting point. A useful replacement should reduce dependence on the person who built it, not create a new version of that dependency.
The cover illustration represents phone-based access. It is conceptual artwork, not a screenshot of the hotel’s live records.
If this sounds familiar
Start by finding out what the program, integration or spreadsheet does, who depends on it and what would happen if its developer became unavailable. Talk to Felix about the right first step; commissioned work starts with an agreed scope and price.


