Most of the software decisions in a self-storage business are made before anyone treats them as decisions. The PMS came with the acquisition. The gate system is whatever the contractor fitted. The payment provider is the one the first site signed up with in a hurry. Nobody chose a stack. It piled up.
I've operated storage for 24 years, and the pattern looks the same in the UK, on the Continent and in Asia. The stack doesn't collapse. It erodes. The month-end report slips by a day, then two. A site manager leaves and nobody can explain how online bookings get into the PMS. Eventually the owner or the finance lead becomes the thing holding it all together, and growth stops being limited by demand and starts being limited by them.
When that happens depends mostly on how many sites you run. Here's what I'd want in place at each stage - and what I wouldn't bother with yet.
Up to 5 sites: keep your options open
At this size a messy stack is fine. The owner sees every number, knows every tenant in arrears by name, and can fix most problems with a phone call. An enterprise platform here buys you licences and admin work, not control. I wouldn't suggest it.
Where operators get hurt at this stage is lock-in. A PMS that can't run multiple sites under one login. A gate system with no API. A booking widget that only talks to one PMS. A payment provider that doesn't operate in the next country on your list. Each is cheap today and painful to unwind at site twelve.
So before any purchase, ask one question: would I still want this with ten sites, possibly in two countries? If the answer is no, buy something else, or buy it knowing you'll replace it.
While it still costs nothing, write down your definitions. Is occupancy measured by units, by area or by revenue? When does a reservation become a move-in? When is an account in arrears? At five sites this takes an afternoon. At fifteen it's a project, because by then every system has quietly decided for you.
5 to 15 sites: decide how everything connects
Most operators first feel the pain here, and it usually shows up in finance before it shows up in operations. The symptoms are consistent.
The numbers don't tie. Occupancy from the PMS, revenue from the accounts and cash in the bank tell slightly different stories. Someone spends days every month reconciling them, and nobody fully trusts the result.
Reporting belongs to a person. One person builds the monthly pack from exports. When they're on holiday, the pack is late. When they resign, it's gone.
Customers are duplicated. A tenant with units at two sites is two records, maybe in two systems, with two sets of contact details and two separate conversations with your team.
Acquired sites never fully arrive. The last acquisition is still on its old software because the migration kept getting pushed back.
More software won't fix any of this. What fixes it is a target architecture: a clear decision on which system owns the tenant record, which owns the money, which owns access and which owns the customer conversation, and how data moves between them so it's entered once and correct everywhere. You rarely need to rip everything out. Most operators get there by consolidating onto one PMS, connecting the customer-facing tools to it properly, and retiring the spreadsheets that were filling the gaps.
If you operate across borders, this stage gets harder. Different currencies, different VAT or GST treatment, different languages on the website and in the contact centre - and in some markets, customers who expect to message on WhatsApp or LINE rather than call. Each country tends to grow its own small stack. Decide early whether you're running one stack with local settings, or several stacks with a reporting layer on top. Either can work. Drifting between the two doesn't.
15 to 40 sites: you're running a data business
Past fifteen sites, the big calls - where to acquire, how hard to push rates, when to refinance - depend on numbers you have to trust without checking them yourself. The architecture is now a board-level problem. Treating it as an IT ticket is how operators at this size get surprised.
Here's the shape the stack needs.
One owner per domain. Tenants live in the PMS. Money lives in the accounting system. Conversations live in the ticketing platform. The website, revenue management, access control, call handling and any AI voice tools read from and write to those systems instead of keeping private copies.
Reporting that assembles itself. Leadership reporting should pull from connected systems into one central reporting layer on a schedule. If someone is still pasting CSVs together at thirty sites, the design is wrong, and hiring another analyst won't change that.
Integrations the company owns. Every connection documented: what it moves, how often, what happens when it fails and who fixes it. If that lives in one person's head, you have a key-person risk, and it tends to surface at the worst moment - usually in the middle of an acquisition or a lender's data request.
Advice with no product attached. Every vendor in this industry will offer to design your stack for free, and the design will put their platform at the centre. That's their job and I don't hold it against them. Your job is to get a view from someone who isn't selling the product, because at forty sites you're betting years of operations on one vendor's roadmap.
Build one stage ahead, not three
Over-building is the same mistake with a bigger invoice. I've watched operators with eight or nine sites buy the data warehouse and BI tooling they saw at a much larger group, then spend a year or more implementing systems their business couldn't yet feed.
My rule is to build for the stage you're in plus the one directly ahead, and stop there. Knowing what to refuse is half of architecture.
And yes, some operators run 25 or 30 sites on spreadsheets and goodwill and look fine from the outside. Some of them are fine. But their management team spends its week reconciling instead of growing, and when they go to sell or refinance, the other side's due diligence finds out how hard it is to prove the numbers. That costs real money at exactly the moment it matters.
A test you can run tomorrow
Ask three people - your finance lead, your operations lead and one site manager - for last month's occupancy. Don't tell them why.
If all three come back with the same number, from the same source, inside an hour, your stack is in decent shape for your size. If you get three different numbers, or three different sources, or a request for a few days to pull it together, you've just found where your next stage of growth will break.
Then ask each of them where their number came from. Write the answers down. That's your real architecture, drawn by the people who use it every day - and it's usually quite different from the one on the vendor's slide.
Mapping that out and sequencing the fixes for the next stage is the architecture work I do with operators through Unwired Logic's Senior Advisor engagement.
← Back to the blog
