KAOS didn't come from a business plan. It came from a university lab, a fest that needed a website, and a student who didn't know that "no" was an option.
Suresh went on to build a remarkable design career of his own. Some early collaborations define what you reach for later.
It was 2009, second year of engineering. The university's annual technical fest was approaching and, as always, the coordination problem was enormous: dozens of institutions, hundreds of students, sixty-member rosters per team, seven days of events. The university had been managing all of it by hand.
Karthikeyan built the entire application himself — every institution could log in, upload their student rosters, and register which students would compete in which events. Design was handled by Suresh, a collaborator who went on to a distinguished design career. The rest was Karthikeyan: architecture, development, deployment. Clean. Accountable. Nothing like it had existed at the university before, and nothing like it has since.
Word spread. People who needed websites started being referred his way. He needed a name for what he was doing. KAOS — a wordplay on his nickname, Keya — stuck immediately. Keya's work became KAOS.
"We loved the build process. The maintenance felt like a drag. So we built the thing that made it less of one."
After graduating in 2011, KAOS was formalised quickly — legally registered, with structure and clear responsibilities from the start. Ashrith was the first person to join, bringing the team beyond a solo operation. Sudeep came aboard a few years later. The roles were defined. The expectations were high. Close friends, yes — but run like a real company from day one.
Over the years, KAOS collaborated with many brilliant designers. Shreya was one of the early external collaborators — a vendor whose partnership became a recurring relationship and set a standard for how KAOS thought about design work: bring in exceptional people, give them real problems, let the work speak.
It didn't take long to notice a pattern in the client work: the build was energising, the maintenance was a grind. WordPress was either overkill or underpowered for the problems KAOS kept solving. So they built their own: KPanel, an internal meta-framework backed admin panel on PHP and MySQL — the right stack for the time, built for the specific problem they kept encountering.
KPanel wasn't just a tool. It was the first signal of something that would define KAOS for years: when the existing solutions don't quite fit, build the right one.
Some of the clients KAOS worked with in this period became unicorns. KAOS was there before that happened. That's how you know you were paying attention.
The JavaScript ecosystem was evolving at a pace that rewarded the curious. KAOS followed it: Django for backend depth, Swift and Java for native iOS and Android applications, then a full embrace of the JavaScript frameworks that were redefining what a web application could be.
Meteor was one of those frameworks. KAOS didn't just use it — they rebuilt KPanel on top of it and released it as open source. That decision reflected something important: if it's useful to us, it's probably useful to others.
The client work expanded in sector and ambition. Broadcast networks managing complex content pipelines. Construction companies modernising operations that had run on paper for decades. Early-stage SaaS founders building their first real systems. The common thread was always the same: a product that needed to be built seriously, with real architecture, not just assembled quickly and handed over.
Clients were spread across the US, Europe, and India. A few of them would become unicorns. KAOS had been there first — working with them when they were still figuring out what they were building.
"We stopped optimising for team size and started optimising for user outcomes. Those are not the same thing."
When Covid hit in 2020, KAOS was a lean five-person team. That constraint turned out to be a clarifying one — the work that survived the uncertainty was the work that genuinely mattered, with clients who treated their products as essential rather than optional. The team stayed tight, stayed focused, and kept shipping.
By 2021, KAOS had grown again — this time to fifteen people across product, UX, UI, development, testing, and DevOps. It was the largest the team had ever been. For two years, that scale produced significant work across serious clients. But it also produced something less welcome: more coordination overhead, more management, more distance between the people making decisions and the problems being solved.
By 2023, the decision was made deliberately. Smaller. Sharper. Less energy on team management, more on what users actually need. Serverless architecture — already embedded in how KAOS built — became the backbone that made a small team viable at real scale. Significant workloads run on it. It holds.
Generative technology entered the toolkit in 2024. Not as a gimmick — as a genuine execution accelerant. The judgment about what to build and why remains human. The speed at which the right things get built has changed substantially.
Through all of it — the growth, the contraction, the platform shifts, the tooling cycles — the founder has worked on every project KAOS has taken on. That's not a policy. It's what accountability actually means.
"She'd made this HTML page — pink background, marquee running across it — just to say this is our computer. I looked at it and thought: how did she do that?"
Karthikeyan Sekizhar grew up in Bangalore. In his ninth grade, in 2004, his family got their first personal computer. His sister Hemalatha — who had learned HTML and CSS in 10th grade at school — created a webpage to mark the occasion. Pink background. Marquee text scrolling across it. Declaring: this is ours.
He watched her make it. Then he went and looked at how the page was actually built. And the thing that hit him — the thing that didn't let him go — was the realisation that all of it was just text with rules. Every colour, every layout, every element on every website he'd ever visited. Structure that, if you understood it, would do exactly what you asked.
Every spare hour with the computer from that point on went to learning. HTML first, then CSS, then vanilla JavaScript. That was all he knew. For a while, it was more than enough.
To pay for the domain and hosting, he went to a bank with a pay-in slip. No bank account. He found a way anyway.
In 11th grade, he came across a publication called Free Ads — a pink newspaper that listed over three hundred paying guest accommodations across Bangalore's neighbourhoods. It was the pre-smartphone era of the city's tech boom: migrant workers would arrive, pick up the paper, and try to find somewhere to live. The process was slow and manual and full of gaps.
He saw a problem worth solving. He built pginbangalore.com — typed out every listing from the newspaper, organised by area and gender, with a dropdown on the homepage that routed visitors to the right static page. No database. No PHP. Just HTML, vanilla JavaScript, and a clear picture of what someone searching for a room actually needed.
He updated it weekly as the Free Ads listings changed. He wired up Google AdSense. It made money. To buy the domain and hosting in the first place, he'd walked into a bank with a pay-in slip — no bank account, no one else to ask — and figured it out.
That was the first product. It worked because he'd thought about the person first — arriving in Bangalore with a newspaper and a hope — and built backwards from what they needed.
He was halfway through Learn PHP in 24 Hours when the university fest opportunity arrived. He put the book down and started building.
The static-page model of pginbangalore.com had limits that became more obvious the longer he maintained it. In his engineering years, he picked up a copy of Learn PHP in 24 Hours — the canonical self-teaching text of that era — and started working through it.
He didn't finish it. Partway through, the university fest opportunity arrived. What he'd already learned was useful enough. What he didn't yet know, he figured out on the way to the deadline.
That combination — structured learning, applied immediately to a real problem, before he was theoretically ready — was the pattern that would define how he worked for the next sixteen years. Not studied theory eventually followed by practice. Theory and practice simultaneously, on something that actually mattered to real people.
KAOS followed directly from that. It always has.
These didn't come from a strategy session. They came from watching what worked, watching what didn't, and paying attention to the difference.
KAOS is a product engineering partner built for companies that want their products to keep improving — not just get built and handed over.
Three engagement verticals. The same standards across all of them. Capacity intentionally limited so every client gets the real thing.
If that's what you're looking for, we'd like to talk.
KAOS works with clients across US, Europe, and India. Remote-first by design. The quality of the work doesn't depend on proximity.