Self-storage management software, built inside a working facility.

The operational core is built. A unit can be listed, held, booked online, papered with a signed agreement, invoiced, paid for by card, chased when it falls behind, transferred to a different unit and closed out with a settlement — without any of those steps living in a separate system that has to be reconciled afterwards.

Around that sit the things a facility needs on an ordinary Tuesday rather than in a demo: a drawn floor plan that reads live unit state, one queue that computes the day of work from overdue accounts and failed payments and departures, door credentials with a history of who was turned away, and reports an operator can save, schedule and have emailed to them.

• Customers, units, unit types, reservations, rentals, move-ins, move-outs and transfers.
• Interactive facility maps: buildings, floors, zones and drawn objects linked to live units.
• Invoicing, partial-payment allocation, proration, card payments, saved cards and autopay.
• Staged arrears with stage fees, collection notes, promises to pay and lockout scope.
• Versioned storage agreements, multiple signers and a sealed, hashed final document.
• Tenant door credentials, an access-event feed, failed-access alerts and access windows.
• Multi-site management with organisations, regions and site-scoped staff access.

Because it is the part an operator cannot inspect from a demo, and the part that is expensive to get wrong quietly. Every vendor can show you a revenue chart. The harder question is whether the numbers underneath it can be rewritten later, and by whom.

Ledger entries here cannot be edited or deleted, and that is enforced by the database as well as the application, so it holds even for a path nobody remembered to guard. Accounting periods close, postings into a closed period are refused, and who closed the period is recorded. Four financial test files are frozen by checksum, which means no future build can weaken a money invariant without that showing up as a deliberate change in the diff.

A correction is therefore a new entry rather than a quiet edit. That is slightly less convenient and considerably easier to defend.

It follows the customer. This sounds obvious and frequently is not, because many systems model the rental as the thing that owes money — so moving a tenant from a 50 sq ft to a 100 sq ft ends one rental and starts another, and the balance can quietly detach in between.

Here the balance belongs to the customer ledger, and debt continuity is checked inside the transfer operation itself. Where a customer in arrears may still be moved, the override is checked against a capability and audited with a reason, rather than hidden inside an unrestricted status edit.

It is worth testing this in any vendor demo, including this one. Put a balance on an account, transfer the unit, and look at the balance afterwards. It takes about four minutes and it tells you how the system is modelled.

The data boundary is built. The assistants are not, and we will not imply otherwise.

What exists is the part that has to exist first: customer personal data cannot be transmitted to an external model merely because somebody has pasted in an API key. A request is a list of classified parcels rather than a block of free text, so what may leave is decided by data type rather than by pattern-matching a prompt for something that looks like a name — detection is a heuristic, heuristics have false negatives, and a false negative here is the incident. No provider is named anywhere in that layer; the operator chooses, per capability and per site.

Four capabilities will eventually sit on top of it — an operator assistant, a booking assistant, a voice agent and operational monitoring. All four are in development and currently run against a simulation adapter. There is no working assistant to demonstrate today.

Permission is enforced per column, not per page. A role can see every unit and its status across all three inventory views and never see a tenant balance or contact details — the two questions are answered separately rather than by opening or closing a whole screen.

That rule came out of finding a real leak in our own system: the site map was returning tenant names, balances and document counts to anyone who could view it. The fix was to move the boundary from the page to the column, and the per-role behaviour is now pinned by its own test file so it cannot drift back.

A site is also a session property rather than a URL parameter. A parameter may select which site you are looking at; it can never be what authorises you to look.

Three words, and they are used strictly. Available means it exists, is covered by tests and can be used. In development means it is being built now. Planned means it is not part of the product.

These are held against a capability matrix pinned to a specific commit in the product repository, and re-pinned as part of closing each build wave rather than as a marketing task. That discipline exists because it already failed once in the more interesting direction: the matrix went nine days without being re-pinned and ended up forbidding claims for ten capabilities that had shipped and were covered by tests. Nothing published was false — the product was simply invisible.

An operator for whom Direct Debit is non-negotiable. Card payments and saved-card autopay work, but a scheduled attempt against a stored card is not a bank mandate, and no charging adapter exists for one. That is a commercial decision about a second gateway rather than an engineering gap, but the practical answer today is still no.

An operator buying AI. The boundary that would make an assistant safe is built; the assistants are not, and a demo would find nothing to show.

An estate that needs single sign-on, a custom report builder, spreadsheet export or a sales pipeline. None of those exist. And nothing here is priced publicly, has a published customer count, or carries reviews — if that is what you need to evaluate a vendor, this is not yet the vendor to evaluate.