Dear reader,
Imagine this: your website needs a small update, a new board member's bio, a broken link fixed, nothing dramatic. But the person who built the site is long gone, nobody on staff can log in, and the developer you eventually track down quotes you more to figure out what's already there than it would have cost to build the thing from scratch.
That's platform lock-in, and it rarely announces itself at launch. It shows up later, quietly, as the reason a straightforward update becomes a six-week saga, or the reason an association keeps paying for a platform it's outgrown because leaving would mean starting from zero.
The lock-in isn't always the software
It's tempting to think of lock-in purely in terms of proprietary systems, a membership platform that won't export your data cleanly, or software that only runs on one vendor's servers. That's real, and worth asking about directly before you sign anything. But the more common version I see is quieter than that: an open platform, built in a closed way. WordPress itself is about as portable as software gets, but a WordPress site built with a heavily customised, undocumented theme, or a page builder configuration only one developer has ever touched, can be just as locked-in in practice as a genuinely proprietary system. The platform was open. The build wasn't.
What to actually check before you commit
A few honest questions, before signing anything, tend to surface the real answer faster than asking a vendor directly whether you'll be locked in, because almost nobody says yes to that question even when the honest answer is yes.
Can you export your own data, right now, without asking permission? Not "in theory," actually try it.
If your current developer disappeared tomorrow, could someone else pick up where they left off? A reasonably competent developer, not specifically the one who built it.
Is your content and configuration sitting in standard, exportable formats, or trapped inside a proprietary export format only one tool can read?
If the answer to any of these is genuinely uncomfortable, that's worth knowing now, while it's still a conversation, rather than in three years when it's a crisis.
Why I build the way I do
This is part of why I build primarily in WordPress with Divi rather than a proprietary website platform. Not because it's flashier, it usually isn't, but because it means a client isn't dependent on me specifically. If I disappeared tomorrow, the site, the content, and the hosting would still belong entirely to the association, and any competent WordPress developer could pick it up.
The same logic applies on the iMIS side, in a different form. iMIS itself is a proprietary platform, that's simply the reality of choosing it, but the parts I focus on, content, member journey, communications integrations, are deliberately the parts that stay yours regardless of who's implementing them.
Ownership is the real question
None of this is really about which platform is technically best. It's about who actually owns the thing at the end of the project, the association, or whoever built it. A platform that's genuinely yours costs a little more thought upfront, asking the uncomfortable questions, checking the exports actually work. A platform that isn't costs considerably more later, at the exact moment you can least afford the surprise.
Until next week,
Brock