Most association executives don't need to know what Docker containers are.
But they need to know whether the platform their association runs on will be available on a Tuesday morning when 400 members try to pay their bills at the same time. They need to know whether the vendor they're trusting with their membership data is running on infrastructure that scales when needed and recovers when something goes wrong. And they deserve a straight answer about why those choices were made.
So here's the straight answer.
Built On The AWS Platform
Tangilla is built on Amazon Web Services, which means it runs on the same cloud infrastructure that powers a significant portion of the internet. The serverless architecture we use means there are no physical servers to patch, no maintenance windows that take the system offline, and no backups we're managing ourselves. AWS handles that. When traffic increases — during a bill cycle, during a large event registration window, or at any moment when many members are doing things at once — the infrastructure scales automatically to meet it. When traffic drops, it scales back. The platform's capacity is always available because it provisions dynamically rather than being fixed to whatever we sized it to handle on a normal day.
The uptime commitment for the load-balancing layer alone is 99.99%. That's not a marketing number. That's an Amazon Web Services Service Level Agreement.
On the application side, Tangilla's member portal and AMS are built as single-page applications using AngularJS — the same framework that powers parts of YouTube and Google's DoubleClick platform. What that means in practice is that the application behaves more like software than a website. Pages don't reload. Transitions are immediate. The experience is closer to a desktop application than to the clunky web forms that have defined association management software for 20 years.
The API-first approach is worth explaining because it matters to associations more than it might seem. Every function in Tangilla is accessible through a documented API built to OpenAPI 3.0 standards. That means integrations are possible, predictable, when we need to connect Tangilla to another system. MLS platforms, lockbox, state license databases — the connections work because the architecture was designed for them from the beginning, not added as an afterthought.
This matters when an association asks whether Tangilla can integrate with their MLS. The answer is yes, and the reason it's yes is architectural, not coincidental.
Solid Technology Choices
The technology choices Tangilla made aren't exotic. They're the choices that serious software companies make when they're building something they intend to run reliably at scale for a long time. Modern infrastructure. Documented APIs. A framework maintained by Google. Cloud architecture with no maintenance windows.
The association executive who doesn't know what a Docker container is doesn't need to. What they need to know is that the platform will be there when their members need it.
It will be.
