Background Millions of working adults quietly run a second job: coordinating care for an aging parent. The scheduling, the transport, and the daily check-ins land in the middle of the workday, and employers have started treating that load as a benefits question rather than a private one. Software that takes it on has to handle voice interaction, third-party logistics, and health-adjacent personal data at the same time. For an early-stage product, that combination raises the bar on infrastructure long before the first user signs in. Client Our client is a voice-activated aging-care coordination platform, sold to large enterprises as a corporate wellness benefit for employees who are informal caregivers to aging family members. Voice wellness check-ins, a shared calendar, transportation, and shopping coordination sit in one place, so care tasks can be handled by speaking rather than by juggling apps and phone calls. Challenge The product itself existed only as a prototype, with no real cloud infrastructure behind it. There was no environment separation, no security hardening, no CI/CD, and no observability. The workload also ruled out the obvious low-cost answer: long-running webhook callbacks from a third-party voice AI vendor, scheduled background jobs, and a need for persistent database connections. Choosing the wrong hosting model would surface as cold starts and timeouts once real users arrived, and there was no in-house DevOps team to weigh those trade-offs or to run the result afterwards. The work needed to cover: A production-capable AWS environment, built from zero Environment separation and security hardening CI/CD pipelines for both the API and the frontend Observability that could trace a single request end to end A hosting model suited to long-running callbacks and scheduled jobs Authentication for enterprise and individual users Notifications, asynchronous processing, and scheduled job handling Payments and ride-ordering integrations Four core modules taken to QA-passed, cutover-ready state All of it without the client hiring an in-house DevOps function Solution We ran the engagement architecture-first, then build. Infrastructure was treated as the first phase of delivery rather than something to catch up on later, which meant the AWS foundation was provisioned, secured, and CI/CD-enabled before any application feature work started. 1. A hosting model chosen against the actual workload We evaluated AWS Lambda against ECS Fargate for the backend, judged on how the product actually behaves rather than on a default. Lambda’s execution time limit and cold starts were a poor fit for long-running vendor callbacks and persistent database connections, so we chose Fargate. At pilot scale the difference came to roughly 15 to 45 USD per month, a marginal cost against the reliability it bought. 2. A production AWS foundation from zero We stood up the full environment: a VPC, an Application Load Balancer fronted by WAF, ECS Fargate for the API, S3 and CloudFront for the frontend, and PostgreSQL on Amazon RDS. A single Amazon Cognito user pool handles authentication. EventBridge and SQS carry scheduled and asynchronous jobs, and SES and SNS handle notifications. 3. Automated delivery from day one Pipelines for the API and the frontend were built in that same first phase, before there were features to deploy through them. Every change since has gone out the same way, so releases were safe and repeatable from the start rather than retrofitted once the codebase had grown. 4. Observability and security, with cost held in view We designed a structured logging strategy in CloudWatch built on correlation IDs, so a single request can be traced end to end across services. We also made a deliberate call to skip AWS OpenSearch for the pilot, since CloudWatch Logs Insights alongside the relational database covered the real reporting and audit needs at a fraction of the cost. Security was hardened in the same phase rather than after it. Automated pipelines, hardened infrastructure, from day one. DISCOVER MORE Key technical implementations WAF rules applied at the load balancer Least-privilege IAM roles per service Secrets held in AWS Secrets Manager Encryption at rest and in transit Correlation ID based request tracing in CloudWatch CloudWatch alarms and dashboards Route 53 for DNS Stripe for payments, Uber API for ride orchestration A mock voice service standing in for the vendor integration during development One part-time DevOps engineer, at 25 percent allocation, owned infrastructure, CI/CD, monitoring, and deployment automation across the whole engagement. Embedding that role inside the delivery team, rather than running it as a separate workstream, is what let the client reach a pilot-ready environment without standing up an in-house DevOps function. Results Four core modules went from architecture proposal to QA-passed, cutover-ready MVP in about five months, between March and September 2026. The AWS environment behind them was complete and automated before the first feature shipped. Delivery automation Automated release coverage rose from 0 percent to 100 percent, across both the API and the frontend Pipelines were operational in the engagement’s first phase, before any feature work began Every API and frontend release since has gone through the same automated path Infrastructure 14 production AWS services went live from a starting point of none Network, compute, database, authentication, security, and CI/CD were all provisioned and hardened ahead of feature delivery Secrets management, CloudWatch alarms, and dashboards were completed as the pilot approached go-live Reliability and cost No infrastructure-related blocking incidents occurred through MVP cutover readiness Open items at cutover readiness were all application-level, a payment retry path and a reporting screen, rather than infrastructure gaps A quarter-time DevOps allocation covered the entire pilot environment, so no in-house DevOps hires were needed The largest risk to the timeline sat outside our control. The third-party voice API contract was not finalized when architecture work began, so rather than wait on it, we specified the expected contract upfront and built a mock voice service against it. Build and operate your AWS infrastructure without hiring an in-house team. SEE HOW