Suresh Mathew Wants to Give You Your Afternoon Back

Suresh Mathew has spent a considerable part of his career doing something he would prefer other engineers never had to do. He has tuned infrastructure, adjusted resources, and worked on the machinery that keeps applications available. The work matters. His affection for repeating it appears limited. Looking back on his own optimizations, he offers a wonderfully unromantic assessment: “Not one of them was exciting to me.”

This is a useful starting point for understanding Sedai, the company he leads. Its founder has a practical objection to the way engineering talent gets spent. A person capable of building a new product can instead find the day occupied by decisions about the size of the machines beneath it. Then traffic changes. Then the exercise begins again.

There is something faintly comic about employing inventive people to keep revisiting a configuration. The cloud promises elasticity; the engineer supplies the patience. Mathew’s answer has been to build software that can take on more of those decisions itself, with customers deciding how much authority to give it.

That ambition required him to change jobs in two senses. He left a large technology company to start a business. He also had to learn that engineering a solution and persuading another person to depend on it are separate occupations.

A safety net, written in 2017

Mathew’s route to Sedai ran through Oracle, Nokia, and more than a decade at PayPal. His public professional history also includes HCL Technologies. He studied computer science at Mahatma Gandhi University in Kerala. At PayPal, he became a Senior MTS Architect, working on infrastructure whose mistakes could quickly become somebody else’s interrupted transaction.

A technical article he published in August 2017 gives the later company a useful prehistory. PayPal then had more than 2,500 internal applications and 100,000 instances across its infrastructure. Treating all those applications as though they responded identically to incoming traffic would produce a convenient answer. It would also miss how differently the individual applications behaved.

Mathew described a process for learning what an instance could handle by carefully directing live traffic toward it and monitoring the result. Safety checks, stopping conditions, and restoration were built into the process. Applications were profiled continuously, allowing new code to produce new measurements. A capacity estimate could age; the system needed to keep learning.

Read that work alongside Sedai and the continuity becomes visible. Mathew was already interested in how software could make useful operational judgments without requiring developers to keep supplying fresh answers. The problem had moving parts because the applications themselves kept moving.

At PayPal, he worked with Benji Thomas, now Sedai’s co-founder and CTO, on an autonomous infrastructure system. By 2022, that internal project was reported to be performing more than two million autonomous remediations a year. Mathew and Thomas had encountered a recurring problem at substantial scale and built something their own employer could use.

Sedai’s account includes a telling detail: their system became trusted to make production changes during peak hours. Busy periods are an awkward time to discover that your automation has a creative streak. Earning permission to act then gave the founders a reason to believe the approach could travel beyond PayPal.

The dangerous kindness of a good meeting

A successful internal system brings advantages to a startup. It brings experience, an observed problem, and a working argument about what might solve it. It does not bring every future customer’s priorities along for the ride. Mathew had to discover where the experience generalized and where a new buyer needed something different.

He has described the personal adjustment plainly: his early enthusiasm centered on autonomous systems themselves. The shift came when he became more attached to the problem customers faced. That is a demanding edit for an engineer. A solution rewards explanation. A problem rewards questions, including the ones that make the original solution inconvenient.

In a 2024 conversation about taking Sedai to market, Mathew identified a small social obstacle. A passionate founder can deliver a pitch and receive approving noises because the listener is being kind. The meeting feels encouraging. The founder still needs to learn what would actually persuade that person to buy.

He sought settings where potential buyers could give candid feedback. Those discussions helped Sedai add support for ECS, Amazon’s container service, alongside Lambda, its serverless computing service. The distinction is technical; the lesson is commercial. Buyers were describing the infrastructure they actually ran, and the product needed to meet them there.

Mathew also drew a boundary around listening. A company cannot build everything people request. It can use those conversations to refine the roadmap. That qualification matters: a founder needs enough conviction to make choices and enough curiosity to revise them. A polite compliment supplies very little help with either task.

“It’s really the last mile of FinOps.”

Suresh Mathew, on turning cloud optimization into action

Permission comes before independence

His sales problem had another complication. Sedai asks customers to consider software that changes the infrastructure beneath running applications. For an engineer responsible for those applications, caution is part of the job. An impressive forecast of savings leaves a perfectly reasonable question: what happens when the software acts?

Mathew’s explanation of adoption gives customers time to answer it. He has described an initial period of roughly two weeks when the system learns and offers recommendations for teams to evaluate. The customer gets to inspect its judgment before handing over more responsibility. The waiting period belongs to the product as surely as the optimization engine does.

This is also a clue to his understanding of the people he sells to. A recommendation has a comfortable distance from its consequences. An action enters the customer’s working day. The person approving autonomy needs a reason to believe that the system understands the application, and a way to see what its decisions mean.

Mathew’s shorthand for the opportunity is the last mile of FinOps: the work between identifying waste and doing something useful about it. That gap is occupied by people with competing priorities. An engineer may agree that a configuration deserves attention and still have a release to finish. A queue of good advice can become another job.

His bet is that reducing the queue requires software capable of carrying more of the operational burden. The human part is arranging the handover. The same founder who learned to ask better questions of buyers was selling a system that had to make its own judgment inspectable.

A bigger company, the same unfinished chore

The company’s growth took Mathew back toward the engineering talent in Kerala. In March 2022, Sedai announced plans for an R&D and product engineering division in Thiruvananthapuram. Mathew described that team as central to the product engineering plan. Thomas emphasized the engineering talent available in Kerala and South Tamil Nadu.

The announcement accompanied a $15 million Series A led by Norwest Venture Partners, with participation from Sierra Ventures and Uncorrelated Ventures. For Mathew, expanding the team meant finding more people to build a product intended to spare other teams repetitive work. Even a business about autonomy needs people who can make careful decisions together.

In June 2025, Sedai announced a further $20 million in Series B financing, led by AVP. The company reported that revenue had grown sevenfold in 2024. Its plans reached into data platforms, GPU optimization, and applications built around language models. Mathew’s familiar infrastructure problem was acquiring new, expensive forms.

He put the ambition directly: “Every company needs a self-driving cloud.” The phrase is broad. The underlying work is specific: understanding demand, choosing resources, and adjusting them while applications continue serving people. His current official biography describes a global team of more than 100 and credits Sedai with eight U.S. patents.

Counting what reaches the customer

By 2026, Mathew was spending time in the interviewer’s chair as well. On Sedai’s 1 IDEA series, he talks with engineering leaders about decisions they have made inside their systems. In April, he sat down with Sedai distinguished engineer Pooja Malik to discuss the company’s approach to GPU optimization, including the inadequacy of standard measurements.

It is a fitting subject for someone whose earlier work involved figuring out what applications could actually handle. A familiar number on a screen can feel reassuring. Whether it measures the thing an engineer needs to know is a separate question. The equipment changes; measurement remains a source of trouble.

In an essay published that March, Mathew argued that AI was forcing software businesses to rethink pricing, infrastructure, and people together. Usage brings computing costs with it. A product can attract customers while its economics deteriorate underneath. He wants autonomous optimization built into that relationship from the start.

His argument about people is equally practical. He urges leaders to upgrade their engineers’ skills, describing a progression from using AI for documentation to testing and more involved coding work. The opportunity he describes gives engineers responsibility for directing and validating what the tools produce. Judgment still has somewhere to go.

In an October 2026 interview, he applied that scrutiny to AI spending and productivity. Counting code check-ins or pull requests, he argued, can reward activity without establishing value. He emphasized the products reaching customers instead. He also argued for keeping model choices flexible rather than tying an agent permanently to one model.

These are recognizable concerns from a founder whose company began with the burden of repeated decisions. If a tool produces more output, someone still has to establish whether the output helps. More code and more computing can make a business busier before they make it better. Mathew wants the accounting to reach the customer.

His original irritation remains unusually easy to understand. Engineers train to build things, then spend a great deal of time keeping existing things in shape. Some maintenance will always deserve their attention. Mathew has made a career of asking which parts could responsibly be handed over.

The promised afternoon is ordinary by design. An engineer can finish a feature, investigate a harder question, or leave a routine configuration alone. For a founder working on autonomous systems, that is a rather human measure of success: somebody else has time to do the work they wanted to do.