Kubernetes vs. ECS Questions for Your Property Software Vendor

Ask what happens to your tenant and maintenance data during a platform outage, and how quickly the vendor can restore service. Ask whether tenant data from different property owners or portfolios is isolated from each other, and how they'd demonstrate that in writing if you asked for it during a security review.

Don't ask whether they use Kubernetes or ECS specifically; that detail matters far less than whether they can answer the isolation and recovery questions clearly and specifically, rather than with a generic assurance.

Put these questions to any property software vendor:

• What happens to our tenant and maintenance data during a platform outage, and how quickly can you restore service?
• Is tenant data from different property owners or portfolios isolated, and how would you demonstrate that in writing?
• What is your uptime commitment for the maintenance-request workflow specifically, not just the platform overall?
• Can we export our tenant and lease data in a usable format if we switch vendors?

A maintenance-request system that goes down during a real emergency, a burst pipe, a lockout, a heating failure in winter, isn't just an inconvenience, it's a liability and a tenant-relations problem. Ask your vendor directly what their uptime commitment is for that specific workflow, not just their overall platform, since a vendor's marketing page rarely breaks that out by feature.

If you're building this in-house rather than buying it, treat the maintenance-request path as the part of the system that most deserves redundancy, regardless of whether it runs on Kubernetes or ECS underneath.

For a property management company with a small internal development team building a tenant portal for a handful of properties, ECS is almost always the more sensible choice: it's less to operate, and a small team doesn't need Kubernetes's advanced scheduling features for what's typically a modest amount of traffic from tenants checking rent statements or submitting requests.

Kubernetes becomes worth considering only if you're operating at the scale of managing portals for many separate property owners as a service, where the multi-tenant isolation features genuinely earn their operational cost.

For context, hosting typically costs around 5% of ARR at the median for a subscription software business¹. A property management company's internal tenant portal isn't a subscription product with its own ARR, but if you're paying a vendor a per-unit or per-property fee, that ratio is a reasonable sanity check on whether the platform costs baked into your fee look proportionate to a typical software business's own infrastructure spend.

If a vendor's pricing seems disconnected from any reasonable infrastructure cost basis, that's worth a direct question in the next contract renewal conversation.

Insist on a written data-export path: if you ever switch vendors, can you get your tenant and lease data out in a usable format without the vendor holding it hostage? This has nothing to do with Kubernetes or ECS specifically, but it's the practical protection that matters most, and it's worth putting in the contract rather than assuming goodwill will cover it later.

Kubernetes vs. AWS ECS vs. Nomad is a useful background read if you want to understand the underlying tradeoffs your vendor is navigating, even if you never touch the infrastructure yourself.

When a property management client brings a vendor's technical pitch to Taj, MeetMyCTO's AI CTO, for a sanity check, the pattern that comes up most often is a vendor leaning on platform names, Kubernetes, ECS, or otherwise, as a substitute for a specific answer about isolation or recovery. A vendor confident in their setup will answer the specific question directly; one that isn't will redirect to reassurance about which well-known platform they run.

Treat the vendor conversation the same way you'd treat any other operational due diligence: ask the specific question twice if the first answer was vague, and don't accept a platform name as a substitute for the answer you actually asked for.

Many property management companies didn't choose one system from scratch; they inherited a patchwork from acquisitions, each portfolio running its own leasing or maintenance software on its own infrastructure. Consolidating onto one vendor or one in-house system is a real project with real migration risk, tenant data has to move cleanly, and lease terms can't get lost in translation.

If you're facing that consolidation, ask each legacy vendor the same isolation and data-export questions before deciding which system becomes the surviving one, rather than defaulting to whichever system happens to cover the most units today.