About ECP 

ECP is a market-leading SaaS solution that enables senior living communities to better care for their residents. ECP is used in over 8,000 communities. We're looking to further expand by increasing the number of customers that use our software and increasing the scope of how we serve our customers by developing and releasing new products. 

Senior living is deeply under-penetrated with software and ECP is one of the largest and fastest-growing software companies in the industry. We recently raised a growth round of equity to reinvest in our product, technology, and go-to-market. Our mission is to build world-class software that improves the quality of life for seniors and improves clinical, business, compliance, and operational performance for our customers. 

The Role 

Foundation Engineering is a new capability in ECP's Platform organization. Its charter is the path from code to production: the environment an engineer develops in, the pipeline that builds and ships their work, the infrastructure it runs on, and the tooling that makes all of it fast. You'd be the first engineer hired into the developer experience side of it, reporting to the Engineering Manager for Developer Experience. Every delivery team ships on top of what you build. 

Most of it is still ahead of us. Production infrastructure is CloudFormation on AWS today, CI is spread across more than one system, and engineers work in shared, long-lived environments. Where we go next on developer environments and infrastructure-as-code is genuinely open, and you'd have a hand in deciding it. 

You'd start on the inner loop, the part of the day an engineer spends before their code ever reaches the pipeline, then move outward into the pipeline and the AWS infrastructure underneath it. The job is hands-on. You'll write infrastructure code and build tooling, and you'll sit next to the cloud engineers who run our production footprint and pick up production work alongside them. 

The stack. New code is Node and TypeScript. We're migrating off a ColdFusion legacy platform, and the two will coexist for a while, so what you build has to serve both. You won't write ColdFusion. SQL Server and PostgreSQL, a mix of monolith and services, adopting domain-driven design and an event-driven architecture, all on AWS. This is a multi-tenant HIPAA product. Engineers need realistic environments and full visibility into their own systems without the resident data inside them, and that constraint shapes most of what you'll design. Our AI coding tools run on Bedrock inside our own AWS account for the same reason. 

What You'll Build 

The inner loop. Replace shared, slow-to-provision environments with ephemeral ones an engineer can stand up on demand, and solve the multi-tenant test data seeding that makes them realistic enough to trust. Cut local build and test times. Establish golden paths: opinionated, documented ways to build, test, and run a service, so the answer to "how do I start" is one page and one command. 

The path to production. Get us building an artifact once and promoting it across environments instead of rebuilding for each one, and give engineers a feature flag system they trust enough to pull deploy and release apart. Those two are what the rest of our continuous delivery plans are waiting on. Make dependency scanning, secrets detection, and static analysis default steps on every build, and move teams onto a common pipeline as we consolidate. We're a small team and we'd rather adopt a good tool than write one, so knowing when to buy is part of the job. 

The infrastructure underneath it. You'll write the AWS and infrastructure-as-code that your tooling and our environments run on, working alongside the cloud engineers who own our production footprint, and carry the pager for what you build. 

Tooling for AI-assisted development. Our engineers build with AI today, and generating code has gotten far cheaper than verifying it. You'd own pieces of what closes that gap: deterministic builds, test feedback fast enough to stay inside the loop, sandboxed execution, review gates for agent-authored changes, and platform capabilities exposed to agents through MCP. 

What Success Looks Like 

At six months, a build runs once and that same artifact moves through every environment, and engineers have feature flags they rely on to deploy without releasing. At least one delivery team works against ephemeral environments with realistic seeded data. 

Consolidated CI, observability that lets an engineer see their own system in production, and an internal developer portal follow from that foundation. 

Requirements

What We're Looking For 

Required 

• You've built and run production AWS infrastructure and expressed it as code, with Terraform, CDK, Pulumi, or CloudFormation. Networking, IAM, and container workloads are things you've configured yourself, and you've carried a pager for infrastructure other engineers depended on. 

• You've built or substantially rebuilt a CI/CD system that other engineers ship through, and you can say what got faster and how you measured it. Running a pipeline someone else designed isn't the same job. 

• You've made a real system runnable outside production, whether that's ephemeral environments, test data for a multi-tenant application, or containerized local development that engineers besides you actually ran. 

• Name a tool or service you wrote that other engineers used every day, and what it did for them. Much of this job is software. 

• You've built something for engineers outside your own team, and you can talk about both a time it worked and a time nobody adopted it. 

• You've moved other engineers along in how they use AI. It's already how you work yourself, and you know where it holds up and where it needs a human check. We expect our engineers to advocate for this. 

Preferred 

• Feature flag platforms and progressive delivery 

• Kubernetes or ECS at production scale 

• Observability built on OpenTelemetry, distributed tracing, or structured logging, especially where the data itself is sensitive 

• HIPAA-regulated or other compliance-sensitive environments 

• Bitbucket Pipelines, Jenkins, Azure DevOps, or GitHub Actions 

• Test automation frameworks, or contract testing in an event-driven system 

• Building alongside a legacy platform mid-migration, without the luxury of waiting for it to finish 

• Node and TypeScript, internal developer portals, MCP servers