Portal Studio, the full-screen editor hotel teams use to build their guest portal, follows a simple rule: a conflict never overwrites anyone’s work silently. The rule sounds small, but it shapes how autosave behaves and what happens when edits collide. The same care extends to how each section of the editor reports trouble. We think every tool used in daily operations should work this way.
Two people, one draft
An illustration makes the risk concrete. A general manager opens a section of the guest portal and starts rewriting it. A colleague at the front desk opens the same section on another computer and corrects a small detail. Neither knows the other is there.
In a hotel this is ordinary. Teams share work across shifts and departments, so shared pages are a normal part of the day rather than an edge case.
Without care, the case ends in a quiet failure. Either the colleague’s save erases the manager’s rewrite, or the manager’s next autosave erases the colleague’s correction. Whichever save lands last wins. Nobody finds out until a guest reads the wrong thing.
Silent loss is worse than an error. An error message at least admits that something failed. A silent overwrite reports success when the opposite is true. The person whose work vanished has no reason to go looking for it.
Check the server before saving
Autosave in Portal Studio is debounced. It waits for a pause in editing instead of writing on every keystroke, so a burst of typing becomes one save rather than many. Fewer saves also mean fewer moments where two writes can cross.
Before it writes anything, the editor compares against the server revision. Put simply, it checks whether the version on the server is still the one this editor last saw. If it is, the save goes ahead. If someone else has saved in the meantime, the editor treats the situation as a conflict.
The server is the right reference because it is the only copy both editors share. Comparing against it turns an invisible race between two saves into a visible event the editor can handle.
The pattern itself is well known in software engineering. In our view, the discipline lies in applying it even where an edit feels too minor to bother with. A short paragraph in a guest portal feels minor until it is wrong.
A conflict is a choice
When the revisions do not match, Portal Studio does not guess. A conflict never overwrites silently. The person chooses what happens next: load the server version, or try their own again.
The obvious alternatives are worse. Last write wins is the failure described above, made official. Automatic merging sounds kinder, but page content rarely merges cleanly, so a bad merge becomes one more silent edit.
A choice puts the decision with the person who has the context. They know whether their rewrite should replace the newer version or whether they should start again from it. Software does not know that, so it should not pretend to.
The choice also has to be clear at a glance. Each option should say plainly what it keeps and what it replaces. A conflict that nobody can make sense of is just a different kind of silence. It is a small, local case of a principle we apply to agents as well: keep people in control.
Every state is designed
The same care applies when nothing collides but something still goes wrong. Every section of the editor has designed states for the moments between a clean load and a clean save:
- Loading, so a section that is still arriving does not look empty or broken.
- Error, with retry, so a failure says so and offers a way to try again.
- Empty, with guidance, so a section with no content explains what could go there.
- Locked, so a section that cannot be edited presents itself as locked rather than broken.
- Session expired, so the end of a sign-in shows as exactly that.
Each state is a promise about honesty. An endless loading state, a blank panel with no explanation or a generic error all leave a person guessing whether their work is safe. A designed state answers that question before anyone has to ask it.
Designing these states is engineering work, not polish. Each one is a branch the code has to handle on purpose. A state nobody designed still appears on screen. It simply shows whatever the code happened to do.
The session state needs particular care. Because the editor takes the hotel from the signed-in session, an expired session has to be stated clearly rather than left to fail quietly. Our aim is to hold the rest of the interface to the same standard, part of the stance described in build for outcomes, not more tabs.
None of this shows on a good day. It shows when two people edit the same section at once, or when a connection drops mid-sentence. In those moments an editor either protects someone’s work or loses it without a word. We build for the first outcome, because the people using the editor have a hotel to run and no time to redo lost work.
