Minus $5,000 for the weekend. How a forgotten deployment turned into a product

6 min read
Empty office at dawn. A curved monitor on a developer's desk shows a 'Cloud Cost Overview' dashboard: low teal bars for Monday through Friday around $100 each, then two tall red bars for Saturday and Sunday labeled $5,000. A second monitor shows a chat app; a coffee cup steams next to a keyboard.

The origin story of Idlefy — and how flipping a single default saved one team $108k a year.

TL;DR — A Friday Kubernetes deployment ran the whole weekend and cost $5,000 for nothing. The fix wasn’t a smarter alarm or a stricter policy. It was flipping the default: instead of “on, don’t forget to turn off,” make it “off, turn on when you need it.” That one inversion turned a side-project Telegram bot into Idlefy.

Monday morning

Monday morning. I open AWS Cost Explorer and feel something sink. $5,000 for Saturday and Sunday. Five thousand dollars. Nobody was working. On Friday someone spun up an environment in Kubernetes and forgot to turn it off. A day of that environment cost $2,500. Two days — five grand for thin air.

But to understand why that exact moment became a turning point, I need to rewind.

A sense of injustice

I was a regular DevOps engineer at a large AdTech company. When we started leaning on expensive GPU machines in AWS, the cloud bill went vertical. At some point I asked myself a simple question:

Why are we paying for something nobody is using?

A developer works 8–9 hours a day. We pay for 24. Weekends — paid. Vacations — paid. Sick days — paid. Around the clock, money draining for servers nobody’s logged into.

It wasn’t my money. Nobody was holding me accountable for it. But the sense of unfairness wouldn’t leave me alone — call it professional deformation. I knew exactly what was behind every line in the bill.

Python, cloud API access, a week of spare time, AI assistance — that was enough to write a simple Telegram bot with two buttons: on and off.

Flipping the question

The first version worked on the principle “don’t forget to turn it off when you leave.” It failed.

Because I figured out one important thing: developers don’t care about the company’s cloud bill. And you can’t blame them — that’s normal. They think about code, architecture, deadlines. The bill lives somewhere else, in another department, in a different reality. Expecting someone to remember the “turn off” button every evening means you don’t understand how people work.

So I flipped the concept. Instead of “on by default, don’t forget to turn off” — “off by default, turn on when needed.”

That’s how rentals appeared. A developer hits one button in a Telegram bot — a VM starts for a specified time. 20 minutes before the lease ends — a warning. 5 minutes before — another. Need more time? One click extends. Didn’t extend? The VM stops automatically.

The idea was so simple I doubted it would land. Developers loved it. They didn’t have to think about anything — one click, workspace ready. One click, extended. Turning it off? Not their problem.

That simplicity gave the company close to 80% savings on virtual machines. Who would have thought flipping the default was enough?

The five-thousand-dollar Monday

The bot worked. The VMs saved money. I kept improving it in spare time — analytics, better notifications, more cloud providers. A regular pet project.

Then that Monday happened.

On Friday a team spun up an environment in Kubernetes with expensive GPU machines — every hour of idle time costing like a nice dinner. Then they left for the weekend. The environment ran for two days at $2,500 a day. Five grand for nothing.

Same human nature. Same pattern. Only the scale was different.

The fix suggested itself: the same rental principle, but for entire environments. Instead of the cloud API, the bot triggered GitHub Actions. Press a button in Telegram → deployment pipeline runs. Rental ends → cleanup pipeline runs automatically. As simple as the VM case.

The unplanned side effect surprised me more than the savings. In our Slack the same conversations played on loop every day: “Who’s holding staging right now?”, “Can I deploy to dev-3?”, “When does QA free up?” Someone wouldn’t answer, someone missed the message, time disappeared. Once we had environment rentals, the problem simply vanished. Everyone could see which environment was busy, by whom, and until when. No more roll calls — it was on the screen.

From bot to product

Two concepts — VM rentals and environment rentals — had proved themselves. 80% savings, zero forgotten servers, no more Slack roll calls. At some point colleagues at other companies started asking: “Can you set this up for us?”

That’s when I first thought: what if this isn’t a pet project but a product?

Deciding wasn’t easy. A bot for your own team — where you know every server by name — and a platform that has to work with someone else’s clouds with no margin for error are not the same shape. I rewrote everything from scratch.

The same AdTech company where it started became the first paying client. The people who’d seen the bot from the inside trusted the product — and that’s the best validation you can get.

Today Idlefy is a team of developers and testers, a microservice architecture, a web interface, a macOS widget, Telegram and Slack bots, audit and analytics. The core kept the same principle: your resource is one click away, and you don’t need to think about turning it off — the system handles that part.

Numbers that speak for themselves

That same team where it all started — about ten engineers at the AdTech company — ran nearly a thousand rental sessions over 136 days.

Without IdlefyWith IdlefySavings
$49,301$8,849$40,452 (82%)

Annualized, that’s over $108,000 saved for one team of ten people. Money that goes back into product development instead of burning for nothing. And that’s only the VMs — add the “not forgotten” environments, the ones that started this whole story, and the picture gets louder.

”Won’t you break our prod?”

The first client’s first question. Fair — I’d been the person handing out and revoking prod access for years. So Idlefy is architecturally incapable of doing harm:

  • No SSH. We don’t enter your machines.
  • Cloud API only. A smart on/off button, nothing more.
  • No static keys. Workload Identity Federation, minimum privileges.
  • Worst case if Idlefy itself were breached: an attacker can turn off your dev machines. Unpleasant — but no data access, nothing destroyed, nothing irreversible.

Sometimes I still think about that Monday with the $5,000 in Cost Explorer. If we’d already had Idlefy then, those five thousand simply wouldn’t have existed. The lease would have ended Friday evening, the cleanup pipeline would have run on its own, and Monday would have started without that feeling in my stomach.

Idlefy is what that Monday looks like when it never happens.

How does your team handle forgotten resources in the cloud — have you been bitten by these? Solved it systematically, or living with it? For the broader industry context — what changed between 2016 and 2026 and why this matters now — see From ‘ship it’ to ‘shut it down’. The RSS feed has more posts in this thread.