November 10, 2025
The best technical solution is usually the simplest one that actually works.
We had an ETL pipeline running on AWS Lambda - serverless, elegant, modern. Then it started failing randomly.
After digging through CloudWatch logs, we found the culprit: the Python script occasionally took longer than 15 minutes, hitting Lambda’s hard timeout limit.
The “impressive” solution? Architect a Step Functions workflow with chunking and state management.
The solution we actually used? A cron job.
Yes, cron. That Unix utility from 1975. Running on a schedule. No serverless complexity. No timeout mysteries.
Anyone on the team could debug it. No one needed to understand Lambda configurations or serverless architectures.
Why simple wins (especially on lean teams):
- Maintenance burden matters more than elegance when you’re the only one who’ll touch the code for the next 6 months
- “Everyone can understand it” beats “technically impressive” when your team is 2 people wearing 5 hats each
- Simple solutions ship faster, which means you learn faster whether you built the right thing
- The best architecture is the one that solves today’s problem without creating tomorrow’s mystery
The tricky part: Knowing when to level up
That cron solution? It works beautifully when runs are predictable and failures are rare. But if we needed complex dependency management, retry logic with exponential backoff, or parallel execution across multiple pipelines, we’d eventually hit its limits.
The skill isn’t just building simple - it’s recognizing the tipping points:
- When manual steps start consuming more time than automation would take
- When the same bug keeps appearing because the simple solution lacks guardrails
- When “just one person knows how this works” becomes a risk instead of efficiency
- When the workarounds to keep the simple thing working become more complex than a proper solution would be
I’ve seen teams waste months over-engineering solutions for problems they didn’t fully understand yet. I’ve also seen teams cling to quick fixes long after they became bottlenecks.
The sweet spot? Start simple. Monitor the pain points. Upgrade strategically when the cost of simplicity exceeds the cost of complexity.
The question I ask:
“If I go on vacation tomorrow, could someone else maintain this?”
If the answer is no, I either need to simplify or document better. Usually both.
What’s your go-to test for whether a solution is appropriately simple vs. dangerously oversimplified?
