CampStay LMT: From First Deployment to Business Infrastructure
An engineering postmortem about what happened when a working application met real-world operations.
- Production engineering
- Hospitality operations
- Lessons learned
- Flagship
Revised 15 Oct 2026 · Written from the founder's account. Technical specifics are described qualitatively pending stakeholder review.
Our first major operational deployment taught us something no prototype could fully demonstrate: a system can be technically functional while still being unprepared for the realities of daily business operations. CampStay began as an accommodation management application. It evolved into an operational platform supporting booking workflows, guest coordination, pricing decisions, and staff responsibilities. That transition exposed gaps in our testing and release assumptions. This is the story of what we underestimated, what it cost, and what we changed.
The Beginning
A developer meets a real business problem
A camp in Koh Samui needed a better way to run accommodation: who's staying where, who's arriving, what's owed and what needs cleaning. Spreadsheets and messages weren't keeping up.
Custom software made sense because the camp's workflow didn't fit an off-the-shelf booking tool. This was the founder's first publicly released project at this operational scale.
Nobody sat down on day one and planned a full operations platform. It started as an accommodation app.
The Build
From app to operations platform
Accommodation grew into interconnected reservations, deposits, pricing exceptions, guest coordination, front-desk views, housekeeping and records.
Every connection made the system more useful. Every connection also meant a change in one place could show up somewhere else. More integration, more capability, more operational risk.
The Miscalculation
We thought we were ready
Our operational lead on the ground in Koh Samui and the founder were both excited to roll it out.
The platform was tested. But the testing reflected how a developer uses software, not enough of how a front desk uses it on a busy day. That gap is the miscalculation.
Enthusiasm outran release verification. Shared excitement about a launch doesn't erase the developer's technical responsibility for it.
The Reality Check
Beyond the monthly subscription
After launch came extra troubleshooting and fixes. Some financial displays looked wrong or confusing to the people reading them, even where the underlying records were accurate.
This wasn't some ten-dollar app subscription quietly renewing on the company card. Fixing it cost real hours, real operational friction and real money — a lot more than anticipated. The kind of avoidable headache that makes you stare at your release checklist and swear you'll never deploy like that again.
To be clear about what didn't happen: no evidence of lost customer revenue, corrupted books or a security breach.
The Correction
Changing release readiness
The displays were corrected and rechecked against the stored records.
The bigger change was how we define "ready." We now treat three things as separate checks: database truth (the right values are stored), calculation truth (totals, deposits and balances add up) and presentation truth (every screen shows them with the right labels, currency and context for the person reading it).
Formal pre-release gates are being written as internal policy. Until they're in daily use, we don't claim them as deployed.
- Stored data
- Correct records and transaction values persist.
- Calculations
- Totals, deposits, balances, discounts and derived numbers are correct.
- Presentation
- Correct formats, labels, currency, status and meaning on every relevant screen.
The Lesson
Deployment is not the finish line
Shipping an app and operating business infrastructure are different jobs. The second one includes monitoring, maintenance, stakeholder handoffs, incident response, dependencies, changing requirements and ongoing testing.
The job is not finished when the code works. It is finished when the system works for the people who depend on it — and even then, maintenance continues.
Lego and Jenga
Software is Lego during construction and Jenga during maintenance.
Lego is assembly: frameworks, databases, libraries, APIs and screens snap together into a working whole.
Jenga is dependency risk: a small edit to shared code, a schema, sign-in, price logic or a third-party service can shake something that looks unrelated.
Good engineering exists to reduce the Jenga effect — separation of concerns, clear interfaces, tests, staged releases and a rollback plan. It's a teaching picture, not a claim that collapses are inevitable.
