A storage unit app is a ledger, a notice clock and a gate you do not control.

A unit is a state machine, not a row

Ask a manager how many units are empty and the answer takes longer than you expect. Empty and rentable is one state. Empty with the last occupant's lock still on the door is another. Empty, swept and waiting on a roller door repair is a third. Held for somebody arriving Saturday is a fourth. A self storage management app with one occupied flag per unit will report a number nobody on site believes.

The record that earns its place holds the size, the type, whether it is drive up, interior or climate controlled, the building and floor, the current state, and the date that state last changed. The date is the field people leave out, and it answers how long a space has stood empty. That number tells you the rate is wrong, not the occupancy percentage.

The other half is the walk. Managers do lock checks: down the aisle, unit by unit, does the door match what the system says. An occupied unit with no lock is a phone call. A vacant unit with a lock is a move in nobody recorded, or a lock somebody forgot to cut. Doing that from a phone, through a list ordered the way the aisles run, is the most useful single thing a storage facility app does.

Note the boundary while you are here. This is a fixed inventory of spaces, one renter at a time. If what you need to follow is movable equipment travelling between people and places, that is an asset tracking app, and the model pulls a different way from the first screen.

The gate is somebody else's hardware

Here is the plain version, because it decides what you build. A phone app cannot open a gate. The gate is driven by an operator motor wired to a controller at the site, and that controller reads the keypad and decides. Your app has no wire to it. Anything a phone does about a gate, it does by asking that system.

There are three honest paths. The first is no integration: your app holds the code and the access hours, a person types it at the keypad, and the two systems are kept in step by hand. The second is the access vendor's platform. OpenTech Alliance describes its INSOMNIAC CIA system as controlling gates and unit doors from site keypads, and says third party technology can connect through an open API. PTI Security Systems and Janus International sell comparable systems. We have not verified the terms of any of them, so ask about API access, cost and coverage first. The third is a Bluetooth smart lock on the unit door, which a phone can talk to through the lock vendor's own app or SDK, so native code and a contract.

Two rules follow and they are worth writing on the wall. Never build a process where the only way a customer gets off the site is your app working, because gates fail, networks fail, and the exit has to work without you. And never treat suspend access as instant. It is a request to another company's system. Show the manager when the request went out and when it came back confirmed, not a green tick the moment they tap.

What your app can own outright is what happened afterwards. If you can read entry events, matching them against the rent record answers the questions that really come up: was the unit accessed after the overlock went on, who was on site the night a door was found open. That is reporting on somebody else's data, and it is the highest value integration in the category.

OpenTech Alliance, INSOMNIAC CIA access control

Delinquency is a clock with dates the law fixes

Self storage is unusual. When a tenant stops paying, the operator gets a lien on the contents of the unit and can eventually sell them. Every state that allows it writes down the steps, and the steps are dates and notices. The delinquency ladder is the part of a unit rental app you cannot improvise.

California shows how specific it gets. The Self-Service Storage Facility Act requires the rental agreement to state that the occupant's property is subject to a lien and may be sold if rent or other charges stay unpaid for 14 consecutive days. The agreement must also request, and provide space for, the name and mailing or email address of another person to receive lien notices. Notices may go by email only if the agreement says so and the occupant signed consent, and the owner has to show receipt or send it again by mail. The notice of lien sale has to state a sale date not less than 14 days from mailing.

Read that as a data specification and it writes itself. You need the agreement version the occupant signed, a consent flag with a date, the alternate contact as a real field rather than a note in a comment box, a row for every notice with method and date, and the evidence of receipt on that row. Your state will use different numbers, not a different obligation to prove what you sent.

None of this is legal advice, and shipping an app discharges nothing. Read your own state's act, and have whoever drafts your agreement check the app against it. The point is narrower: the shape of this data is decided for you, so find out what it is before you design the screens. The occupant facing half of the record, where somebody signs in to pay and read their history, is a tenant portal app.

California Business and Professions Code 21712, self-service storage rental agreements

What the manager is actually doing at nine in the morning

The office side is smaller than people expect and far more interrupted. A move in: pick a unit, sign the agreement, take payment, issue a gate code, record the lock. A move out: check the space is empty and swept, clear the lock, put it back to rentable. A rate increase letter. A lock check. A prospect asking what is free this week.

Nearly all of that is answerable from two screens: a unit board you can filter and sort, and an occupant record carrying the ledger and the notice history. Build those two properly and the app is already doing the job. Everything after is reporting, and reporting is cheap once the records are right.

Payments are the decision to make before you start, because they change the shape of the project. Rent recurs, cards expire, and failed autopay is the largest source of delinquency nobody intended. Building your own app means integrating a payment provider yourself, and that provider's rules on storing cards, retrying charges and handling disputes will drive your schema harder than anything else here.

One more thing to settle early, because retrofitting it is miserable. A weekend assistant, a relief manager covering three sites, an owner who wants the numbers and none of the buttons: deciding who may open which unit record is a design question at the start, not a settings screen you bolt on later.