It's 1 PM. An executive wanted an event registration page. He started building it three hours ago.
Last week it was a code-of-ethics validator that uses AI to check submissions. The week before, a forms tool that looks a lot like DocuSign, but isn't. Last month, a finance report that emails itself out on a schedule. A monthly script that pulls a state license spreadsheet from a public website and runs checks against the database to find the agents who hung their license somewhere new.
He's a software engineer. He's two years into a job at a REALTOR® association. And every department in the building has learned where to send the requests their current Association Management System (AMS) can't handle. Him.
He Doesn't Use The AMS
He has read-only access to the AMS he is supplementing with his own work. To update anything, he goes directly into the database. There's no checksum, which means the system has no automated way to detect if data has been tampered with, scrambled, or broken. No write protection. The backend database lacks basic security restrictions or lockouts to block unauthorized or accidental edits. So there is nothing preventing the data from being corrupted.
Even he says it's scary to use.
The gap exists. The AMS can't or won't do the work. Somebody has to. And once that somebody exists, the organization stops asking whether the AMS should do the work in the first place. The executive doesn't go to vendor support. She goes to the engineer down the hall. The finance team doesn't file a feature request. They go to the engineer. Onboarding, certifications, license tracking, member portals, event registration. All of it routed through one person.
He's not maintaining an AMS. He's running a parallel system that makes the AMS look like it works. But it doesn't.
What It Costs
The cost shows up in places that don't look like AMS problems. He used to have two engineers working under him. Both of them left. Leadership didn't approve replacements. Why do we need them? The screen still loads. He's using AI to write more of the code now. That's how he's keeping up. Barely.
He's been telling them for two years that they need to change.
There's a line between customizing a system and replacing it one feature at a time. You don't usually notice when you've crossed it. You just keep adding. A form here, a report there, a script that pulls a spreadsheet on the first of the month. Each piece looks reasonable. The accumulation looks like something else.
He hasn't customized his AMS. He's quietly built another one alongside it.
Before the next executive request, before the next finance request, before the next late-night patch, there's a question worth asking. Which one of those two systems does the association actually depend on?
The answer should be the AMS. We built Tangilla to be that answer.
Book a demo and see for yourself.
