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

Oleksandr Kasianok — Thu, 09 Apr 2026 14:57:38 +0000

Monday morning. I open AWS Cost Explorer and feel something sink inside. $5,000 for Saturday and Sunday. Five thousand dollars. No one was working. Simply on Friday, developers spun up an environment in Kubernetes and forgot to turn it off. A day of this environment running cost $2,500. Two days - five thousand for thin air.
But to understand why this exact moment became a turning point, we need to rewind.

A sense of injustice

I worked as a regular DevOps engineer in a large AdTech company. When we started actively using expensive GPU machines in AWS, cloud bills skyrocketed. And at some point, I asked myself a simple question: why are we paying for something no one uses?
A developer works 8-9 hours a day. But we pay for 24. Weekends - we pay. Vacations - we pay. Sick leave - we pay. Around the clock, without interruptions, money drains away for servers that no one works on.
It wasn't my money. No one held me accountable for it. But some sense of injustice wouldn't leave me alone. Maybe it was professional deformation - I understood too well what was behind every line in the bill.
I knew Python, I had access to cloud APIs, and I had a week of free time. Using AI and my own knowledge, I wrote a simple Telegram bot: it could turn virtual machines on and off via the cloud API. Nothing complicated - just an "on" button and an "off" button.

Flipping the question

The first version worked on the principle "don't forget to turn it off when you leave". And it failed.
Because I realized one important thing: developers don't care about the company's money. And you can't blame them - it's absolutely normal. They think about code, architecture, deadlines. The cloud bill is somewhere far away, in another department, in a different reality. Expecting a person to remember the "turn off" button every evening means not understanding how people work.
And then 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 presses one button in a Telegram bot - a virtual machine starts for a specified time. 20 minutes before the end - a warning. 5 minutes before - another one. Need more time? One click - the rental is extended. Didn't extend - the machine stops automatically.
The idea was so simple that I doubted: would it really work? Developers liked it. They didn't have to think about anything - one click, and the workspace is ready. One click - and it's extended. And turning it off? Not their concern.
It was this simplicity that gave the company almost 80% savings on virtual machines. Who would have thought that simply flipping the question was enough?

The five-thousand-dollar Monday

The bot was working, virtual machines were saving money. I slowly improved it in my free time - added analytics, refined notifications, expanded cloud support. A regular pet-project.
And then that Monday happened.
On Friday, developers spun up an environment in Kubernetes with expensive GPU machines, where every hour of idle time costs like a dinner in a good restaurant. And they left for the weekend. The environment worked for two days, burning $2,500 a day. Total $5,000 for thin air.
The same human nature. The same pattern. Only the scale is different.
And the solution suggested itself: the same rental principle, but for entire environments. Instead of the Cloud API, the bot started triggering GitHub Actions. Pressed a button in Telegram - the deployment pipeline starts. The rental ended - the cleanup pipeline starts automatically. Just as simple as with virtual machines.
But the most unexpected part is a side effect I hadn't planned. In our Slack, the same conversations unfolded every day: "Who is occupying staging right now?", "Can I deploy to dev-3?", "When will QA be free?". Someone doesn't answer, someone didn't see the message, time is wasted. With environment rentals, this problem simply disappeared. Everyone saw: which environment is occupied, by whom, and until what moment. No questions - everything is on the screen.

From bot to product

Two concepts - VM rentals and environment rentals - proved their effectiveness. 80% savings, zero forgotten servers, no more roll calls in Slack. And at some point, colleagues from other companies started asking: "Can you set up the same for us?"
Then I thought for the first time: what if this is not a pet-project, but a product?
Deciding was not easy. It's one thing to have a bot for your team, where you know every server by name. Another - a system that has to work with someone else's infrastructure, in someone else's clouds, with no right to make a mistake. I rewrote everything from scratch - not because I wanted to, but because the architecture of a bot for ten people and a platform for hundreds are different things.
That same large AdTech, where it all began, became my first client. The people who saw the bot from the inside trusted the product - and this was the best validation you can get.
Today Idlefy is a team of developers and testers, a microservice architecture, a web interface, a macOS widget, bots for Telegram and Slack, audit and analytics. But the core retained the same principle: your resource is one click away from you, and you don't need to think about turning it off - the system will do everything itself.

Numbers that speak for themselves

That very team it all started with - about ten engineers in that large AdTech - conducted almost a thousand rental sessions in 136 days. Without Idlefy, the bill for this team alone would have been $49,301. With Idlefy - $8,849. Savings: $40,452, or 82%. Annualized - more than $108,000 for one team of ten people.
And this is money that can be put into product development, rather than burned for nothing. And this is only on virtual machines. If we add "not forgotten" environments here - those same ones that started this story - the results speak for themselves.

"Won't you break our prod?"

When the first client wanted to connect Idlefy, the first question was exactly that. And I understood it perfectly - I myself for years was the person who gave and took away access to the production infrastructure.
Therefore, Idlefy architecturally cannot harm. No SSH - we do not go inside your machines. Only Cloud API - essentially, a smart "on/off" button. No static keys - only Workload Identity Federation with a minimum of privileges. Even if Idlefy is hacked, the attacker will not get access to your data and will not be able to delete anything. At maximum - they will turn off your dev machines. Unpleasant, but without irreversible consequences.

Sometimes I think about that Monday with $5,000 in Cost Explorer. If we already had Idlefy then, those five thousand simply wouldn't have existed. The rental would have ended on Friday evening, the cleanup pipeline would have worked automatically, and on Monday I would have opened Cost Explorer without that feeling in my stomach.
I built Idlefy so that such Mondays never happen again - neither for me, nor for you.
And how are things in your team with forgotten resources in the cloud - have you stepped on such rakes? Have you solved it systematically or do you live with it? Share in the comments, it's interesting to compare approaches and gather collective experience. Idlefy itself is on idlefy.com.