Choosing a SaaS platform over hiring developers doesn't end the build-or-buy question. It moves it inside the platform you bought, where nobody is watching. Every time the software almost does what you need, the question reopens - and if the answer is "we'll just customise it" often enough, you end up running custom software you never decided to build.
Those four words are said casually, which is exactly why they're expensive. In 24 years in self-storage, this is one of the costliest things I've seen happen to operators, mostly because it happens where no one can see it.
Flexibility is the trap
A rigid platform is annoying but safe. It does what it does. Where it doesn't fit, you adapt your process around it. That's frustrating, but it's bounded, and everyone on the team can see the edges.
A configurable platform hands the choice back to you every day. Each gap between what the tool does and what you want gets closed with a custom field, a small integration, a workaround. Every one is minor. Every one is defensible. That's why they pile up. Nobody builds a monster on purpose. They build it one reasonable change at a time.
The day you look up
Two years later, look at what you're actually running. Custom fields stacked on custom fields that only make sense if you were there when they were created. A few integrations moving data between systems. Spreadsheets covering what the platform never quite handled. Automations holding the joints together. And one person - probably you, or a single manager - who understands how it all fits.
That isn't a configured platform. It's a custom system, assembled in steps small enough that nobody had to admit they were building one. And it carries every cost a build carries. It breaks when a vendor changes something underneath it. It needs maintenance nobody scoped. Its single point of failure is a person. When that person leaves, you don't inherit a system - you inherit a puzzle with no picture on the box.
I once watched an operator run his whole rate strategy out of spreadsheets bolted onto the side of his PMS, because the PMS "almost" did dynamic pricing. It worked well, and it existed nowhere except in his head. Multiply that across a portfolio and you can't even see all the exposure at once.
Where configuring ends and building starts
Configuring is using the settings the vendor gave you, the way they meant them to be used: rates, unit types, fees, notice periods. You're filling in blanks someone designed for you.
Building is bending the software into doing something it was never designed to do - tying together fields, integrations and outside tools until the seams disappear.
The test is simple. Could a new manager work out how this runs just by reading the screens? If yes, it's configured. If it only makes sense to the person who put it together, you built something.
None of this means building is wrong. Sometimes a limitation deserves to be escaped, and a build is the right answer. The failure is doing it by accident - carrying a fragile, expensive system while still telling yourself you bought software.
Make it a decision
When the tool doesn't fit, catch the reflex. If the answer is automatically "we'll customise it," stop and make it a real decision instead of a habit. A build instinct running on a buy budget is how operators end up with something nobody can keep alive once one person walks out.
Storage is a straightforward business. This is one of the classic ways operators make it complicated - turning a simple tool into an intricate machine, one small change at a time.
So look at the gap and choose on purpose. Either accept the limitation and move on, or commit to the build with its full cost, upkeep and key-person risk in plain view. Both can be the right call. The wrong one is building something you'll have to maintain forever while pretending you bought it.
Deciding which gaps to live with and which to build for, before they decide for you, is what our Fractional CTO engagement is for.
← Back to the blog
