Almost everyone who offers to design your technology stack is selling you part of it. That's the quiet problem in self-storage technology, and most operators never name it because the help arrives free and feels generous. It isn't free. You pay for it later, in a stack built around someone else's product roadmap instead of your operation.
The pattern is the same everywhere I've worked - Japan, the UK, the Netherlands, Australia. An operator is growing. The systems are straining. There's no senior technology person on staff, because at fifteen or twenty sites the salary doesn't make sense. So they turn to the one group who plainly understands storage technology and is happy to help: the vendors.
The vendor sends a solutions consultant. The consultant is sharp, knows the industry, asks good questions and hands over an architecture. Every arrow on it points back to their platform.
This isn't a piece about bad vendors. Some of the best technology people in this industry work for software companies. It's about what a vendor is built to do, and why that isn't the job you need done.
What a vendor is built to do
A software vendor exists to sell and retain software. That's not cynical, it's the business model. When they advise you, the advice can be completely honest and still start from one fixed conclusion: the answer involves more of their product.
A vendor can't tell you their own module is the weak point in your stack. They can't tell you to keep a competitor's system because it fits you better. They can't tell you to skip their add-on and use something simpler. Not because they're dishonest - because you're asking a question their business can't answer against its own interest.
Think about what you're actually doing when the vendor designs the stack. You're asking the company paid to sell you more to decide how much you need. You wouldn't let a builder paid by the square metre decide how big your next facility should be. You wouldn't take investment advice from the person earning commission on the trade. In technology, because it feels specialised, operators hand over exactly that decision - and then wonder why the recommendation is always to expand the platform they're already on.
What the job actually is
Someone has to sit on your side of the table and answer questions nobody selling a product can answer cleanly.
What do we keep, and what's holding us back? A straight answer means being willing to say "the system you already pay for is fine, don't replace it." That costs a vendor a sale.
Where do we build, and where do we buy? Sometimes the honest answer is "build nothing, you're over-engineering." Sometimes it's "don't buy that module, it'll lock you in." Neither is available to someone earning on the module.
What does this cost us in three years, not three months? Vendors sell on the near-term win. Lock-in, migration cost, data you won't own, the integration that only works while you stay on their platform - those are year-three problems, and the person recommending the purchase isn't accountable for any of them.
Who owns it when it breaks? When the vendor-designed stack doesn't scale, the vendor doesn't own that. You do. The consequence lands on the operator every time, so the decision should be made by someone whose only interest is the operator.
In every other industry that runs on technology, that role has a name. It's the CTO seat - the person who holds the architecture, makes the build-versus-buy calls, manages the vendors instead of being managed by them, and answers to the owner instead of a sales target. Growing operators need that seat filled long before they can justify hiring for it. So it stays empty, the vendors fill the gap, and the gap is the problem.
The fair version of the other side
For a lot of operators, most of the time, following the platform's recommendation works out fine. If your needs are standard and you're early, the bundled path is easier, and a good vendor's stack will serve you for years.
Independence matters at the decisions that are expensive to reverse: the system that owns the tenant record, who owns the data, how everything connects, and the platform you'll build a decade of process on. On small, reversible calls, take the easy path and don't overthink it. The point isn't "never trust a vendor." It's "don't let the vendor make the decisions you can't take back."
The obvious objection: independent advice costs money and the vendor's advice is free. True. But the vendor's design is only free the way a free quote is free - the cost sits in the purchase it steers you towards and the flexibility it quietly removes. An independent advisor is a line item you can see. A vendor-designed stack is a cost you discover later, usually on the day you try to change something and find out you can't.
One question to ask
Before you take the next architecture recommendation, ask the person giving it: what would you tell me to do that costs you money?
If the answer is "nothing" - if every recommendation they've made also happened to grow their invoice - you don't have an advisor. You have a salesperson. Nothing wrong with that, as long as you know which one is sitting across from you.
The mistake isn't listening to vendors. It's confusing the person selling the tools with the person who's supposed to stop you buying the wrong ones.
Filling that seat for operators who aren't ready for a full-time hire is what our Fractional CTO engagement is for.
← Back to the blog
