I was running an $8 million company. Most of the work was on AWS, Kubernetes clusters, the standard sprawl of services around them, all of it growing as the company grew. The kind of infrastructure where you stop thinking about the line items and just trust that the platform team has it under control.
The bill came in one Monday and I noticed something odd. It wasn't just up, it was up by a number that didn't match anything we'd done that month. No new product launch. No traffic spike. No migration. Just a bill that had quietly grown 40% over the previous quarter while I'd been looking at customer metrics, hiring decisions, board prep, every other thing a CEO is supposed to be looking at.
That sounds minor. It wasn't. When you're running an $8 million company, a 40% jump on cloud spend isn't a line item you adjust at quarter-end. It's the difference between hiring two engineers and hiring zero. It's whether the runway forecast you showed the board last month was real or fiction. It's a hole in the budget that nobody told you was forming until it was already there.
I asked the platform team what was happening. They told me the truth: the bill was high because the cluster was over-provisioned, and they'd been meaning to do something about it, but they were stretched thin. The recommendations had been sitting in the FinOps dashboard for months. Nobody had time to act on them.
I was furious. Not at the platform team, they were doing the right thing for the company, prioritising customer features over backend cost work. I was furious at the situation. We were paying for capacity we didn't need. The tools that were supposed to surface this had surfaced it. And the system as a whole had no path from "we know where the waste is" to "the waste goes away."
That weekend, I called Ashutosh.
ASHUTOSHPrince and I had been friends for years. We'd worked together on and off, talked about building something together for longer than either of us would admit. When he called me that Saturday, I was expecting him to vent about his bill, which he did, briefly, and then move on to whatever else was bothering him that week.
What happened was different. He described the situation: the bill, the dashboard recommendations, the platform team that didn't have bandwidth, the gap between identifying waste and eliminating it. And then he said the thing I'd been waiting for somebody to say.
"This isn't a problem with our company. Every Kubernetes shop has this exact problem. Why does nobody have a real solution?"
I'd been thinking about this for a year. Maybe two. I'd worked with enough Kubernetes infrastructure to know exactly the gap Prince was describing. The dashboards were good. The recommendations were technically correct. The implementation cost was so high that nothing got done. And the autonomous tools that promised to fix it required a level of trust most teams couldn't afford to give a third-party platform on production.
I told Prince something I'd been keeping to myself: I thought there was a billion-dollar idea sitting in this exact gap. Workload-aware AI that produced recommendations engineering teams could trust. Recommendations that flowed through normal CI/CD. Read-only by default, no platform taking write actions on production. The intelligence layer separated from the execution layer.
It wasn't a new idea in the abstract. The autonomous platforms had a piece of it. The dashboards had a piece of it. But nobody had built the architecture as the destination state, advisory-first as the philosophy, not as a stepping stone to autonomous. The space was wide open.
PRINCEAshutosh built a prototype in three weeks. Read-only collection from a Kubernetes cluster. Workload-aware analysis. Recommendations that respected SLO tiers, burst patterns, batch cycles, the things engineers care about when they're deciding whether to act on a recommendation.
We installed it on the cluster I'd been complaining about. The one that had blindsided me with the bill. We let it run for two weeks while I went back to running the rest of the company.
When we looked at the recommendations together, two things hit me at once. The first was that the analysis was sharper than anything our existing tools had produced. Not vaguer "this pod might be over-provisioned." Specific: "this pod is requesting 4 GB of memory, peak observed usage is 1.2 GB, 95th percentile is 1.6 GB, you can right-size to 2 GB with safety margin and capture this much per month." The kind of recommendation an engineer reads and immediately knows is right.
The second thing that hit me was the size of the opportunity. Across the cluster, the recommendations added up to something close to a 60% reduction in our cloud bill. Sixty percent. On infrastructure we'd built carefully, with a competent team, using all the tools the cloud provider gives you.
If our company, well-funded, technically competent, paying attention, had 60% waste in our cluster, every other Kubernetes shop in the world had something similar. The optimisation opportunity wasn't a niche. It was the entire market.
I went back to the platform team with the recommendations. We implemented them over the next month, carefully, through normal change-management. The cluster utilisation went from somewhere in the 30s to somewhere in the 60s. The bill dropped exactly as the model had predicted. Nobody had to make a heroic engineering effort. Nobody had to take execution risk. The recommendations were precise enough that implementation was almost mechanical.
That's when I knew this wasn't a side project. This was the company.
The decision to leave
I'd built a company before. I knew what it took. I knew how brutal it was. I knew that walking away from something that worked to start something new, even something with this kind of upside, wasn't a casual decision.
I called Ashutosh again. Different conversation this time. We talked about what it would take. Capital. Runway. The first hires. The first design partners. The kind of customers who would help us build the platform versus the kind who would slow us down. The compliance-heavy ICPs that nobody else was serving well. The long timeline to get into BFSI and government, and why those were the right segments anyway.
Ashutosh went full-time first, in January 2026. He'd been working on the platform part-time while still at his previous role. I followed shortly after, transitioning from the previous company. We registered OptOps.ai. Set up shop in Gurugram, proximity to BFSI customers in the NCR, talent depth from Flipkart, Paytm, Razorpay alumni networks, capital efficiency at roughly a quarter of the Bay Area burn rate.
By March we had a working product. By April we had our first design partners. By the time we launched publicly in November 2025, sorry, the company technically launched then; the journey started months earlier, we already had a clear picture of who we served and why.
ASHUTOSHThe first paying customer was a major government contractor. Not the kind of logo most early-stage startups would expect to land. We landed it because the architecture we'd built, read-only, metadata-only, no write access, recommendations through CI/CD, happened to fit exactly the constraint stack that government and BFSI buyers operate under. Most autonomous tools fail security review in those environments. We were designed to pass.
The second paying customer followed within months. Both serving as design partners while we matured the platform. A public-sector pilot followed shortly after, and the pipeline grew faster than we expected.
None of that came from clever sales motion. It came from the same recognition Prince had on that first cluster. When teams running Kubernetes at scale saw what advisory-first AI could do, workload-aware, SLO-respecting, deployable in environments where autonomous tools were blocked, the pitch was almost unnecessary. They got it immediately because they'd been feeling the gap.
What we believe now
PRINCEMost cost optimisation companies start with a cost optimisation thesis. We started with a frustration thesis. The frustration was real, the gap was real, and the architecture that fit the gap was different enough from what existed that we could see the shape of a category around it.
Three things we believe now that we didn't fully believe when we started:
Advisory-first is the destination, not a stepping stone. Some of our customers will eventually want more automation. We'll add it. But the architecture we lead with is the architecture that fits the buyers we care about most, regulated industries, compliance-heavy environments, teams where engineering accountability for production matters more than maximum convenience. We're not trying to convert advisory customers into autonomous customers. We're trying to be the best advisory-first platform in the market.
The gap between recommendation and action is the whole game. Every cost optimisation tool generates recommendations. The ones that capture savings are the ones that make acting on the recommendation cheap enough that it happens. That's what the integration with CI/CD is. That's what the precision in the recommendation is. That's what the workload-awareness is. The recommendation isn't the product. The cost-of-acting is the product.
Climate matters more than we realised. When we started, we talked about cost. The deeper we got, the more we realised that aggressive Kubernetes optimisation is also aggressive carbon reduction. Every pod we right-size is compute that doesn't run. Every node we eliminate is energy that isn't consumed. We didn't set out to be a climate company. The math says we kind of are.
What's next
ASHUTOSHWe're 18 months in as a building entity, six months in as a launched company. The technology is real, the customers are real, the pipeline is real. What we're building toward over the next two years is platform depth, better workload awareness across more workload types, deeper integration with the deployment tooling our customers already use, expansion into the layers above and below pod-level optimisation.
We're also building toward category leadership in advisory-first specifically. The market is converging, autonomous-first vendors are bolting on advisory modes, and there's going to be confusion about what advisory means. We want to be the platform that defines what real advisory-first looks like, deployed at scale, in environments other categories can't reach.
PRINCELooking back at that Monday morning when the AWS bill blindsided me, the one that started all of this, I'm still occasionally amazed that nobody else in our company saw what was coming. We had a competent team. We had good tools. We had budget visibility that most companies would envy. And we still got blindsided.
The lesson worth carrying away from this is simple. If our company missed it, your company is missing it. Probably worse. The 60% number wasn't an outlier, it was fairly average for a Kubernetes shop that hasn't aggressively optimised. The waste isn't visible until somebody who knows where to look comes looking. And in most companies, nobody is looking, because the people who could look are busy doing other things that the business prioritises.
That's the gap OptOps.ai exists to close. It's not glamorous work. It's not the most exciting category in tech. But it's real, and it matters, and we've built the company we wished had existed when we needed it.
If you're feeling the same gap we felt, bills climbing, dashboards full of recommendations nobody acts on, optimisation tools that don't fit your environment, we'd be glad to talk. The product is read-only by default, installs in 15 minutes, and either delivers a real recommendation set on your actual cluster or tells you we can't help. Both are useful answers.
Thanks for reading.
Prince & Ashutosh