"Build or buy?" is the wrong question. The right one: does this make customers choose you, or does it just need to work?
I operated self-storage for 13 years, and I've sat on both sides of this decision - as the operator tempted to build, and as the consultant called in after someone did. The pattern is consistent enough that I'll state it as a rule: buy the commodity, build the difference.
If it just needs to work, buy it
PMS, ticketing, payments, accounting, storage-specific AI tools - these are solved problems. Vendors maintain them, patch them, secure them, and keep them working when the systems around them change. That last part is the one everyone underestimates.
Here's what the build quote never shows. Custom software isn't a purchase - it's a subscription paid in maintenance. Your custom code needs updating every time a connected system changes its API, which is constantly. It needs securing every year it exists. It needs explaining every time a new person arrives, and the developer who built it has the only real documentation in their head. The day they leave, you own a black box that your gate system depends on.
I've watched operators spend serious money building their own version of something a vendor sells for a modest monthly fee - and the build is the cheap part. Five years of keeping it alive is where it gets expensive, and none of that was in the original quote because the person quoting had no incentive to put it there.
A custom payment system processes payments. The bought one does too. Your customer cannot tell the difference, which means you spent differentiation money on plumbing.
The difference is the opposite case
Now the other side, because this is not an argument against building. Some things you cannot buy, precisely because buying makes them identical to everyone else's.
Your booking experience. The way a customer gets from "what does a unit cost?" to a paid booking and a working gate code without talking to anyone - at 10pm, on their phone, in one sitting. Operators win real business on exactly this, and a custom booking portal that nails it is a completely valid build. The off-the-shelf booking flow is the same one every competitor has; the friction you remove that they didn't is yours alone.
The way your systems talk to each other. The integration glue that makes a booking flow into the PMS, fire the access code, start the billing, and notify the team - one motion, no rekeying. No vendor sells your exact combination of systems working as one thing.
If a customer would notice it and choose you because of it, that's the difference. Build it.
Keep every build thin
When you do build, build like someone who knows the maintenance bill is coming.
Thin means the custom layer sits on top of bought systems rather than replacing them. The booking portal calls the PMS's API - it doesn't reimplement unit management. The integration glue moves data between vendors' systems - it doesn't become a shadow database. Documented means a new developer can understand it without the original one in the room. Replaceable means if the build fails or ages badly, you unplug the layer and fall back to the bought systems underneath, instead of performing surgery on your own spine.
Thin builds keep the maintenance bill proportional to the value. Thick builds - the custom PMS, the homegrown CRM, the everything-platform - start as an asset and mature into a hostage situation.
The test
Before any build, one question: would a customer notice?
Would they choose you, stay longer, or tell a friend because of this thing? Your booking flow - yes. Your custom invoice generator - no chance. They're renting a box. They notice speed, simplicity, and whether the gate opens. They will never notice your back office, no matter how lovingly it was built.
If they'd notice, build it thin and make it excellent. If they wouldn't, buy it, configure it well, and spend the difference on something they would.
← Back to all writing
