A mobile inspection and asset-condition platform for hotel owners. Onsite staff
walk a property on a phone and tap only what fails. That data becomes out-of-order room tracking,
vendor accountability, and eventually a defensible capital and renovation plan. The buyer is
the owner. The report is the product.
1
Overview
Origin: discovery lunch with Mandeep, Aug 5, 2026.
Hotel condition data is created every day by people with clipboards and then it dies. Nobody
aggregates it, so owners cannot answer basic questions: which rooms keep failing, which vendors
are slow, what needs replacing next year, and what deferring it costs. This platform captures
that data at the point it is created and turns it into owner-facing reporting.
The value ladder
Each rung is worth more than the one below it, and each is only possible because of the one
below it. This is a data moat rather than a software moat: a competitor can clone the checklist
in a month and still be two years behind the report that matters.
| Layer | Cadence | Output | Reader |
| Inspection / checklist | daily | Fault records, photos, punch-list | Onsite staff |
| Out-of-order rooms | weekly | Rooms down, days down, revenue at risk | GM, owner |
| Vendor performance | quarterly | Response times, cost of delay by vendor | Owner |
| Capital / renovation plan | annual | What to replace, when, cost of deferral | Owner, lender, buyer |
Why out-of-order rooms is the wedge
An OOO room loses revenue every night it is down. It is the one maintenance function with a
clean dollar figure attached. Everything else in facilities is a cost center you can argue about.
Downtime reduction is directly attributable recovered revenue, which is the only kind of ROI an
absentee owner signs a recurring check for.
2
The partnership
Structure agreed in principle Aug 5. Specific terms not yet papered.
| Party | Contributes | Owns / responsible for |
Brian Lighthouse 27 LLC |
Product, engineering, design, infrastructure, delivery |
The technology and IP. Roadmap and build. Hosting and security. Runs the pilot deployments. |
| Mandeep |
Hospitality domain expertise, industry network, go-to-market |
Customer discovery and validation. Introductions and sales. Defines what "correct" looks like operationally. Meaningful equity. |
▲ Papered before the pilot ships, not after
Equity split, vesting, IP assignment, what happens if one party stops, and who owns the
customer relationships are all open. This document assumes the structure above but does
not set numbers. Get an operating agreement in place before the first free pilot goes live,
because a deployed product with real customers is much harder to unwind than a plan.
3
Goals and non-goals
Non-goals are the load-bearing half.
Goals
- Make a full property inspection completable on a phone in under 30 minutes, offline.
- Give owners a monthly report quantifying downtime in dollars, not tasks.
- Accumulate structured condition history from day one, because the capital report depends on it.
- Prove value in 3 free pilots with small regional hotels before charging anyone.
- Build a business, not a client project. Repeatable, multi-tenant, sellable.
Non-goals for v1
- No PMS integration. The wedge stands alone and integration blocks on other people's certification programs.
- No review-response tooling. Reputation enters as inspection line items, not as a product.
- No renovation report. It needs 12 to 24 months of history. Promising it in v1 means fabricating it.
- No accounting, payroll, or booking. We are not building a PMS.
- No native mobile app. Installable web app first.
4
Users and buyers
The people who use it are not the people who pay for it. That drives everything.
| Role | Uses / Buys | What they need |
| Maintenance tech / housekeeper | Uses | Speed. Big tap targets, works offline in a stairwell, no typing, photo in two taps. If it is slower than the clipboard it will not be used. |
| General manager | Uses | A punch-list that assigns itself, and a score they are measured on. Bonus eligibility is the hook that makes them care. |
| Owner | Buys | Dollars. Rooms down, revenue at risk, which vendors cost them money, what to budget next year. Reads monthly, decides annually. |
| Third-party management co. | Buys | Portfolio rollup and accountability across properties they run for owners, plus a reporting artifact they can hand their owners. |
5
Scope and phasing
Everything discussed is in the plan. Sequence is the discipline, not exclusion.
| Phase | Name | Contains |
| Phase 0 | Free pilot 3 small regional hotels | Walk & Tap inspection, OOO room tracking, punch-list, basic owner report. Given away in exchange for data, feedback and a reference. |
| Phase 1 | Paid v1 | Vendor directory with tap-to-call and auto-logging, work-order assignment and tracking, vendor performance reporting, portfolio rollup, multi-property roles. |
| Phase 2 | Operations depth | Inventory and supplies (par levels, consumption per occupied room, reorder points, vendor-linked). Inspection template library. Guest-feedback line items. |
| Phase 3 | The moat | PMS integration (read room status, later write OOO). Renovation and capital plan report. PIP support pack. Lender and transaction condition export. |
▲ On inventory
Included at Phase 2 per Brian's direction. Recorded honestly: it has a different data model
from condition inspection, no dollar story as clean as OOO downtime, and it does not feed the
capital report. It is in the plan and it is not in the critical path. If pilot feedback pulls
it forward, move it.
6
User stories
Each sized to one working session. Acceptance criteria are verifiable, not aspirational.
P0-1Walk & Tap inspection
As a maintenance tech, I walk the property on my phone and tap only what fails, so a 250-item inspection takes minutes instead of an hour.
Acceptance criteria
- Every line item renders as PASS by default. One tap cycles pass → fail → N/A.
- Items marked N/A are excluded from the denominator, not counted as failures.
- Live score recalculates and is visible without scrolling.
- Tap targets are at least 44px tall and usable one-handed.
- A 259-item inspection can be completed in under 30 minutes by an untrained user.
P0-2Offline capture and sync
As a tech in a stairwell with no signal, I keep inspecting and it uploads when I get service.
Acceptance criteria
- Full inspection completable with the device in airplane mode.
- Taps and photos persist across an app close and device restart.
- On reconnect, sync is automatic and idempotent. Re-syncing never duplicates an inspection.
- Sync state is visible: pending, syncing, synced, failed.
P0-3Photo attach on failure
As a tech, when I flag a failure I attach a photo in two taps so nobody argues about it later.
Acceptance criteria
- Marking an item failed surfaces a camera action inline. No navigation away.
- Photos compress client-side before upload and store in R2.
- Photo is bound to the item, the room and the inspection, and appears on the punch-list.
P0-4Out-of-order room state
As a GM, I mark a room out of order with a reason, and the clock starts.
Acceptance criteria
- Room states: in service, out of order, out of service, with reason and timestamp.
- Every state change writes an immutable history row. Nothing is overwritten.
- Days-down is derived from history, never hand-entered.
- Returning a room to service requires a resolution note.
P0-5Deficiency punch-list
As a GM, the failures from an inspection become an assignable list without me retyping anything.
Acceptance criteria
- Every failed item auto-creates a deficiency with room, section, photo and timestamp.
- Deficiencies can be assigned to a person and move open → assigned → resolved.
- The list is filterable by property, room and status.
P0-6Owner monthly report
As an owner, I get one page a month telling me what my property cost me in dollars.
Acceptance criteria
- Reports rooms down, total room-nights lost, and revenue at risk = room-nights lost × ADR.
- ADR is a per-property input. If it is not set, the report shows room-nights only and says so.
- Inspection score with trend against prior periods.
- Renders on a phone and prints to one page.
- No fabricated or estimated figures anywhere. Missing data is labelled missing.
P1-1Vendor directory and tap-to-call
As a tech, I find the right vendor and call them from inside the work order, and the call logs itself.
Acceptance criteria
- Vendors are per-property records with trade, contact, hours and notes.
- Tap-to-call uses the device dialer. No telephony infrastructure in this story.
- Placing a call writes a contact-attempt row against the deficiency and the room.
- Outcome is capturable in one tap: reached, no answer, scheduled.
P1-2Vendor performance report
As an owner, I see which vendors are slow and what their slowness cost me.
Acceptance criteria
- Per vendor: median time fault → first contact, contact → onsite, onsite → resolved.
- Attributes room-nights lost to the vendor responsible for the delay.
- Suppresses any vendor with fewer than 5 completed jobs and states why, rather than reporting a meaningless median.
P1-3Portfolio rollup
As an owner or management company, I see all properties on one screen with trend and accountability.
Acceptance criteria
- Table of property, latest score, 6-month trend, delta, open items, last walked.
- Role-based access. A GM sees their property only; owner and corporate see the portfolio.
- A user with no properties assigned sees an empty state, never another tenant's data.
P2-1Supplies and inventory
As a GM, I track par levels and know what to reorder before I run out.
Acceptance criteria
- Items with par level, current count, unit and linked vendor.
- Counts are recorded as dated events, so consumption is derivable rather than guessed.
- Consumption normalizes per occupied room-night where occupancy is available.
- Below-par items surface as a reorder list that reuses the vendor directory from P1-1.
P3-1Capital and renovation plan
As an owner, I get a defensible annual plan for what to replace and what deferring it costs.
Acceptance criteria
- Groups recurring failures by room, system and component across the full history.
- Reports quantity and timing. Unit costs are owner-supplied, not invented by us.
- States the observation window explicitly and refuses to generate below 12 months of data.
- Exports to PDF suitable for a lender or a buyer.
7
Business model
Platform fee plus per property, per Brian's direction.
| Component | Shape | Rationale |
| Platform fee | Monthly, per account | Covers the owner-facing layer: portfolio rollup, reporting, capital plan. This is where the value is, so this is where the base price sits. |
| Per property | Monthly, per property | Scales with deployment. Keeps a single-property owner affordable while a 12-property owner pays proportionally. |
| Pilot | Free, time-boxed | 3 small regional hotels. Not a free tier. A time-boxed pilot with a defined end date and an agreed conversion conversation. |
▲ What we get for the free pilot, in writing
A pilot that is only free is a favor. Pilot terms should state what we receive: permission to
use the operational data in aggregate, a named reference and testimonial on success, an agreed
end date, and a conversion conversation at that date. Without those it is unpaid work with no
asset at the end of it.
Price points are deliberately not set here. That is the pricing-strategy pass, and it needs
the pilot to tell us what an owner believes a recovered room-night is worth. What is decided is
the shape: platform plus per property, billed monthly.
8
Brand
Sub-brand under Ascend Systems. Naming and identity are a separate pass.
The product is Provenance, endorsed as "by Ascend Systems." Provenance is the documented
chain of history that establishes an asset's value and authenticity. It is the term of art in real
estate and lending, and it is precisely what this platform produces.
Locked Aug 5, 2026
| Field surface | Charcoal #262A2F. Warm dark grey rather than black. White text sits at 14.44:1. |
| Accent | Carolina blue, specified as a pair. #4B9CD3 on charcoal (4.81:1); #1E6FA8 on white (5.39:1). No single value holds contrast on both surfaces, so neither is ever used alone. |
| Record surface | White, printable. A lender may read it on paper. |
| Type | System stacks only. The field app is an offline PWA, so font payload is a feature. Tabular figures set globally. |
| Canonical source | app/tokens.css. Every contrast figure in it is computed, not estimated. Add no colour without measuring it. |
The one rule that is not decorative
Pass is a neutral outline, never a colour fill. In an assume-pass system, pass is the
default state rather than an event, so colouring 257 passing rows drowns the two that matter.
Failure is the only filled colour on a field screen. N/A is a faded dash and is excluded from the
score denominator entirely. This is enforced in the inspection_scores view, not left to
application code.
Settled independently of brand and not to be relitigated: phone-first layout, the
assume-pass interaction model, the punch-list to work-order flow, and the portfolio rollup table.
9
Technical considerations
Stack matches the house standard. Nothing exotic.
| Area | Approach |
| Stack | Astro + Cloudflare Pages, D1 for relational data, R2 for photos. Proven combination in production on comparable multi-property, role-based applications. |
| Offline | Installable PWA with a service worker and IndexedDB queue. This is the hardest engineering requirement in the product and it should be prototyped first, not last. |
| Multi-tenancy | Per-tenant isolation enforced server-side on every query. Role model: tech, GM, owner, corporate. A cross-tenant read is a P0 bug. |
| Auth | Real server-side session auth. Cloudflare Access is fine for internal and pilot use, but the page must be gated, not just the mutating action. No stubbed verifiers. |
| History model | Append-only event rows for room state and inventory counts. Derived values are computed, never stored as hand-entered truth. The capital report depends entirely on this being right from day one. |
| Schema status | Written and verified. 21 tables and 4 views across three migrations, applied cleanly to SQLite 3.51. Scoring, room-state derivation and revenue-at-risk arithmetic are smoke-tested. See the build plan for detail. |
| Calling (P1) | Device dialer only. No telephony vendor, no numbers, no porting. If an answering or transfer product is ever wanted, the platform selection for that has already been researched separately. |
| PMS (P3) | Start with modern-API vendors. Oracle OPERA has a partner certification program that costs real months and must not gate any earlier phase. |
10
Risks
Named now so they are decisions rather than surprises.
| Risk | Severity | Mitigation |
| Adoption on the floor | High |
If it is slower than a clipboard it dies regardless of how good the reports are. Assume-pass exists for this reason. Measure time-to-complete in the pilots and treat it as a primary metric. |
| The moat needs time | Medium |
The capital report is the differentiator and it needs 12 to 24 months of data. Do not sell it early. Use it as the reason to start collecting now. |
| Partnership undefined | Medium |
Paper it before the pilot ships. See section 2. |
| Unverified market claim | Medium |
The working assumption is that hotel capital planning is served by consultants and heavyweight enterprise systems, leaving small-portfolio owners unserved. This has not been verified and must be before it appears in any pitch. |
| Scope | Medium |
Nine surfaces surfaced in one lunch. All are in the plan; only Phase 0 is in the build. Phase boundaries are the control. |
Open questions
Answering these changes the document. Everything else can proceed.
- Which 3 hotels are the pilots, and who owns that relationship?
Mandeep's network presumably, but the pilot agreement is with an entity that does not exist yet.
- Do the pilot properties have ADR data we can use?
Without ADR the flagship report degrades to room-nights and loses most of its persuasive power.
- What is the entity? Lighthouse 27, or a new company?
Determines who signs pilot agreements, who holds the IP, and how Mandeep's equity is actually issued.
- What does Mandeep think a recovered room-night is worth?
The single input the pricing pass needs most, and he is the only person who can answer it.
▶
Next
Branding and marketing passes are queued, not run.
Per the compound-engineering loop this is the end of PLAN for the product itself. Still to run,
each its own pass: brand-guidelines (name, identity, palette resolution),
marketing-plan (GTM for the two target segments), and pricing-strategy
(the numbers behind the platform-plus-per-property shape). None of them should run before
this document is redlined, because all three inherit its assumptions.