A Mature Setup, an Uncomfortable Question
The team in question wasn’t sloppy. Their AWS environment ran containerized services on ECS, deployed automatically through GitHub Actions, monitored through CloudWatch, and secured with properly scoped IAM roles. On paper, it was the kind of setup that would sail through an architecture review. Nothing was broken.
What changed their minds wasn’t an outage or a security scare. It was a simple question raised during quarterly planning: how much of our time actually goes into infrastructure, versus building things people use? When they pulled their sprint history and calendars to answer honestly, the number that came back was 12 to 15 hours per week spent on infrastructure work that didn’t move the backlog forward — deployment pipeline maintenance, IAM access reviews, dependency patching, and chasing down environment drift and cost anomalies. Spread across a fully loaded engineer’s time, that’s roughly a third of one person’s week, every week, spent maintaining the platform rather than building on it.
This is the core idea worth sitting with: cloud infrastructure has two costs. One is the bill you can see. The other is attention — the engineering hours and mental bandwidth it quietly absorbs. The second cost rarely shows up in a budget review, which is exactly why it can grow unnoticed for years.
When "Automated" Still Means "Only One Person Knows How"
A closer look at the team’s deployment process shows how this attention tax accumulates in practice. Their pipeline was genuinely automated — a push to the main branch triggered a build, pushed an image to a registry, and updated the service, landing in production in about 12 minutes. But automation and resilience aren’t the same thing. Only one engineer fully understood how the pipeline behaved when something broke, whether that was a task definition mismatch or a permissions error. Rollbacks were manual, requiring someone to know the previous image tag and rerun the whole 12-minute process — precious time during an actual incident. New hires needed the better part of a day just to learn the deployment mechanics, and many stayed hesitant to trigger a release on their own for weeks.
None of this is a sign of a badly run team. It’s what happens naturally as flexible infrastructure accumulates operational responsibility: every configuration choice that gives you more control also gives you one more thing that can only be understood by whoever built it.
flowchart LR A[Team ships product features] --> B[Small infra tasks appear: patches, IAM, drift] B --> C[One engineer absorbs the specialist knowledge] C --> D[Deployment gatekeeper role forms informally] D --> E[Team quietly becomes a platform team] E --> F[Less capacity left for the backlog]
That path — from ordinary product work to accidental platform ownership — is easy to miss because each individual step looks reasonable. Patch a dependency here, fix a permissions edge case there. Nobody decides to become an infrastructure team; it happens as the sum of small, sensible decisions.
The Move: Three Weeks, No Heroics
The team migrated to Sevalla, a platform-as-a-service that abstracts away much of the server and deployment management a team like theirs had been handling by hand — a defining feature of the PaaS model in general. The switch took about three weeks and roughly 40 hours of total engineering effort, concentrated mostly in two people. The trickiest part wasn’t the code — it was translating secrets and environment variables into the new platform’s configuration system, and running both databases in parallel for two weeks to confirm data consistency before cutting over, with no downtime reported.
What Actually Changed
The most visible change was deployment speed, dropping from about 12 minutes to roughly 3. Shorter deploy times matter less for the minutes themselves than for what they represent: a shorter gap between making a change and seeing whether it worked, which lets a team catch mistakes while the context is still fresh. But the change the team called most important operationally wasn’t speed — it was that any engineer could deploy confidently from day one, because the process no longer depended on tribal knowledge held by one specialist.
Rollbacks illustrate why that combination — speed plus reduced specialist dependency — matters together, not separately. A safe rollback generally requires reversing application code and any database schema changes in a coordinated way; the team’s new one-click rollback turned what used to be a 12-minute manual process into roughly 30 seconds, and they leaned on it twice in the first month, including once during a failed database migration.
| Dimension | Before (AWS) | After (PaaS) |
|---|---|---|
| Deployment time | ~12 minutes | ~3 minutes |
| Rollback process | Manual, ~12 minutes | One-click, ~30 seconds |
| Weekly infra maintenance | 12–15 hours | 2–3 hours |
| Who can deploy confidently | One specialist engineer | Any team member, day one |
| Time to diagnose a production issue | 10–20 minutes across tools | Under 2 minutes, one dashboard |
Weekly infrastructure work fell from 12–15 hours to about 2–3, a recovery the team estimated at roughly 10 hours per week redirected to the actual backlog — around 130 hours, or about three working weeks, over a quarter. They also noticed better production visibility without extra tooling investment, since logs and deployment history were available directly on the dashboard instead of requiring deliberate CloudWatch configuration.
What They Gave Up
None of this came free. The team explicitly lost infrastructure flexibility: custom networking topology, specialized compute, or fine-grained storage configuration wouldn’t be supported on the new platform. For an internal tools team, that gap hasn’t mattered yet — but it could, if their requirements grow. A few AWS-native components, including some serverless functions, also needed reworking to fit the new model, adding migration complexity they hadn’t fully planned for.
This is the trade genuinely at the heart of the story: less control in exchange for less operational load. It’s not a universal bargain. A customer-facing product with strict compliance needs, unusual scaling patterns, or genuinely custom architecture might need exactly the control this team gave up. Infrastructure simplification shifts effort from platform maintenance toward product work — it doesn’t eliminate operational responsibility, and the team’s own estimates of hours saved are self-reported rather than independently audited.
The Actual Lesson
The team’s own framing is worth taking seriously: the cost of owning infrastructure isn’t primarily what shows up on the cloud invoice — it’s the engineering attention it demands. For a seven-person team, recovering roughly 10 hours a week was described as close to a 28% increase in capacity for user-facing work, a meaningful shift for any team whose backlog already outpaces its bandwidth.
The right question isn’t whether a team is capable of running its own infrastructure — most competent teams are. It’s whether doing so is the best use of the hours they have. For a small team measured by what it ships rather than how elegantly it deploys, that calculation can tip decisively toward simplicity. For a team whose product genuinely needs the control a flexible cloud platform offers, it may not tip at all — and that’s precisely the judgment call every team has to make for itself, not one any single migration story can settle.
