One inventory.
One arithmetic.
One guest.
Most hotel software does not fail because a screen is missing. It fails because two parts of the business disagree about what is true. NiroStay is built around three things that are allowed to have exactly one answer.
A system is only as calm as its least certain fact.
Every screen in the console is a view of one of these. None of them is maintained by a second process that could fall behind.
A room is either free or it is not
Availability is decided inside the database, by a constraint that refuses overlapping assignments for the same unit. Two receptionists, a booking page and an OTA import cannot all win the same night.
A balance is computed, never remembered
A folio's total is charges minus refunds; collected is verified payments only. Both are computed on the server from the rows, so the front desk, the owner's phone and a printed receipt cannot print three different numbers.
The guest meets the property, not the platform
Each booking page carries its own name, colours, logo and contacts; the guest emails that follow are painted from the same layers. The page and the message agree because they read one identity.
From a stranger's search to a closed folio.
The same path whether the guest arrived on your site, on the phone, or through a channel. Staff see the same stay at every step.
- 01
Search or ask
A guest searches dates and occupancy, or sends an enquiry when the answer needs a person. Both land in the same property, with the same availability.
- 02
Hold, then confirm
A hold protects the unit for twenty minutes while the guest pays or decides. A hold is inventory too: the front desk cannot sell a held room.
- 03
The folio opens
Accommodation is posted at the rate in force on each night. Extras, taxes and discounts are separate lines, each with a reason and an actor.
- 04
Money is proved, not typed
A transfer is recorded against a reference; a card payment arrives from the gateway's signed webhook. Only verified money moves the collected total.
- 05
The day closes itself
Checkout queues the turnover clean, the calendar frees the night, and the reports already agree with the folio because they are reading it.
Modules that share a spine.
Each of these is a page in the console, a route in the API and a set of rows in one database — not an integration between products.
Properties, units, rates
Properties hold unit types and units; rates are written per night, or as a weekday/weekend pattern over a window in one pass. A night with no rate is visibly unsellable rather than quietly free.
Reservations and calendar
Create, modify, cancel, check in, check out, no-show, extend and move rooms. Every operation leaves an event on the stay and lands in the audit trail.
Folios, payments, refunds, tax
Charges and receipts with idempotent writes. VAT and levies derived from rules; issued invoices and credit notes numbered from the tenant's own sequence.
Direct site and channels
A branded booking page on your address, with holds and online deposits. The channel manager speaks Channex and keeps a durable inbox and outbox for OTA inventory.
Housekeeping and maintenance
A touch-first queue with photo proof and safe retries. A maintenance ticket can block a unit from sale, and releasing the unit is part of resolving it.
Roles, agents, corporate
Five roles with scoped property access. Agents with commission rules and an append-only ledger; corporate accounts with negotiated rates and invoices.
Branding and addresses
Per-site colours, logo and contacts; the organisation is reached at its own address, and a hostname you own can be proved with a DNS record and served here.
Reports that reconcile
Occupancy, revenue against collected, sources, arrivals and departures — every figure traceable to a folio line and a verified receipt.
Enquiries and guest email
One inbox for guest questions with a thread and a reply that sends from the property's own identity. Confirmations and receipts are sent once, keyed to the thing that happened.
Boring choices, deliberately.
The stack is chosen for what it can refuse, not for what it can show. Platform decisions are recorded as ADRs in the delivery pack.
- PostgreSQL is the referee. A range constraint refuses overlapping stays on the same unit, so a race between two requests ends in a database error, not two confirmations.
- Idempotency keys on money. A payment, refund, charge or booking retried after a timeout reuses its key and cannot apply twice.
- Tenancy from the address, not the payload. Each organisation answers at its own hostname; a token for one organisation cannot act on another's address.
- Gateway secrets sealed. A merchant key is encrypted with AES-256-GCM and only ever returned as a hint. Card numbers never reach the API.
- Capture-first email in development. Locally every message is captured and readable; in production it is sent through Resend or Postmark, with delivery webhooks recorded.
- Receipts and invoices are documents. Numbers are issued from a per-organisation sequence, never chosen by a client, and a credit note corrects rather than deletes.
- Small, testable modules. Every route has a contract and an integration test; the suite runs against a throwaway database, never yours.
- No silent branding. A guest page is painted from the operator's own values, validated before they reach a stylesheet or an inbox.
A real product, honestly early.
This is a pilot-stage platform, not a company with a thousand logos. The parts below are the ones worth knowing about before a walkthrough.
Bookings, money, operations
The core is running: reservations, folios, payments, housekeeping, reports, direct booking, tax documents and team invitations. It has been exercised end to end against a seeded property.
Channels and card acquiring
The Channex adapter is built and tested against a stub provider; live OTA connections are onboarded one property at a time. Card payments work through Paystack with your own merchant account.
Mobile app and PDF packs
Housekeeping works in a phone browser today. Native shells, a staff app and richer document packs are on the roadmap, not on the price list.
Bring the messiest part of your week.
Double bookings, a guest who says they paid, a cleaner who cannot see the task. We will show you what the system does with it — and say so when the answer is still manual.