Abhiraaj Konduru

Most hard problems are just simple ones folded together.

Hi, I'm Abhiraaj. I like figuring out complex things and then building something that makes them simpler.

Scroll down

Before we start

This site is here so you can get to know me.

I'll get to the fun animations soon, I promise. First, I want to tell you what this site is for, and it's pretty simple: I want you to know who I am.

That's also why I'm not going to list every skill I have. The skills that matter change with the work in front of you, and I love learning, so picking up new ones has never been the hard part for me.

Instead, I want to tell you about the most useful skill I have. It's one I don't think people understand well enough, and I think more people should know how powerful it is.

What I believe

That skill is abstraction.

People use that word in a lot of ways, so here's what I mean by it. Abstraction is looking at one thing and seeing the layers inside it: what the pieces are, how they connect to each other, and how they're arranged. Do that enough times and you end up with a mental model you can carry around and use again.

Those layers usually have a hierarchy. Some sit on top of others, and even inside a single layer, one piece can sit underneath another. Seeing that structure is what makes the next step possible. Once something is broken into pieces, you can prioritize the pieces. If you can't break it down in the first place, it's hard to prioritize anything at a high level.

That's also why being stuck doesn't scare me. I believe there's always a model underneath, so being stuck just means I haven't found the right way to look at it yet. I look at the problem through different lenses, and I look at how people in other fields have solved things that look similar, until the pieces start to line up.

I believe almost every problem can be decomposed. Break it down, find the model underneath, then use that model to build the solution. That's where the real power is. You do the hard work once, and then it scales to everyone it can help.

“Intelligence is the ability to avoid doing work, yet getting the work done.”

Linus Torvalds

That's what I think abstraction is really about.

Here's what that looks like.

01 · Unfold

At first, it looks like a mess.

When you pull a hard problem apart, it usually gets worse before it gets better. You end up with a pile of pieces that don't look like they belong together. A lot of people stop here, and I understand why, but honestly this is my favorite part.

02 · Find the pattern

Then the pattern shows up.

So I look at the pieces from different angles. I compare them with other things I've seen and ask what they have in common, and that's when the creases start to show. A crane and a boat start from the same square of paper, and a lot of problems that look unrelated start from the same few ideas. Once you find the pattern, you only have to solve it once, and then you can use it as many times as you want.

03 · Fold it back

Then you fold it into something people can use.

Understanding a problem doesn't help anyone until you build something with it. So the last step is putting the pieces back together, carefully this time, into something simple enough that people actually want to use it.

A quick heads-up: from here on, I'm going to get into the stories behind all of this, and they go into a lot more detail than a quick summary would. If you'd rather not read that much, no hard feelings. You can click off here, or skip to the end.

Skip to the end

Where it's shown up

I didn't learn this from a class. I learned it by noticing it again and again, usually in places I wasn't expecting it.

Chapter 1

The same shape, in different work

The first time I really felt how powerful abstraction is was at Xenspire. Separately from the company's engineering team, I'm building a platform for service businesses as its developer and product lead. Before I built anything, I read the team's SOPs, worked directly with the CEO, and tried to see the work the way a recruiter sees it.

What I noticed is that people in different service based businesses were doing similar kinds of work over and over, and none of it seemed as connected as it could be. When I looked closer, though, the structure was the same every time. Only the details inside it changed. If you build the structure once, you can reuse it everywhere.

Then I noticed something bigger. When you order something online, one page shows you exactly where your package is. When you pay for software, you can see what you're getting the moment you log in. But when a business hires a service firm for a big project, the work shows up through calls, emails, documents, and meetings, spread across a dozen places, and there's no single place to see how it's actually going. Even buying is different: with software you pick a plan and you're in, while with a service it's a back-and-forth of contracts and calls before anything starts.

So I borrowed the pattern. Service work can have the fast feedback and visible progress people already expect from the products they use every day. Some parts should be standardized, like how a client gets started and what they see along the way, so the business can actually scale. Other parts should stay flexible, because that flexibility is the reason people hire a service business in the first place. Deciding which part is which is the abstraction.

For the more technical side

The codebase has grown past 200,000 lines. I'm only mentioning that number so I can say this: lines of code don't matter. What I'm proud of is that I can still move fast at this size, which is usually where codebases start falling apart, and the reason is abstraction.

Every part lives in its own bucket with clear edges, so changing one thing doesn't quietly break something far away. Anything that happens more than once becomes a system. The workflow engine I helped design, for example, turns recruiting pipelines into drag-and-drop templates instead of hardcoded processes.

A quick disclaimer: I don't write code by hand. If you asked me to, I would completely fail. That doesn't mean I don't understand how it works, though. Most of my time goes into the system itself: the architecture, how it connects to the product, and how to keep it scalable as it grows. AI tools like Claude Code, Cursor, and Codex let me work at a higher level of abstraction, and that's exactly why I can move fast and still think about sustainability, scalability, and the actual problem. As AI gets better, I expect to keep getting better at orchestrating it.

My method keeps changing, too. A couple of months ago, I wrote down how I was working at the time in Systems Over Syntax. Back then, it meant breaking work into prioritized, outcome-based phases and layered tasks, then running them in parallel. I'm working on the next article now, and I plan to write a new one every couple of months as the method gets better.

Chapter 2

Build the system once

When I helped organize Boston's regional Divergent Teams hackathon, run in partnership with Microsoft for more than 100 students, I was in charge of sponsorships. The traditional way to find sponsors is to do everything by hand, one cold email at a time. Instead, I went back to first principles and asked how getting a sponsorship actually works. I broke the process down into its pieces, then built a repeatable, AI-assisted outreach system with automations around them.

We raised almost $15,000 in sponsorship value. And because I put in the effort up front to understand every piece of the pipeline, anyone could learn to run the system without having to figure out all that nuance again or rebuild the pipeline from scratch. That's the power of abstraction: do the hard part once, and everyone after you gets to skip it.

Chapter 3

It isn't just for work

I don't only use abstraction at work. I use it every day to get better at how I live and work.

For a long time, I kept trying new productivity apps, and every one of them ended up overwhelming me. So I tried a different approach. I looked at people who are extremely successful and asked what they actually had in common. It wasn't the tools they used. It was their mindset, the way they approached their work. That was the pattern, and once I saw it, changing my own approach helped more than any app ever had.

Daydock is what I built from that. It's a free, open-source planner that runs on plain Markdown files on your own computer, with no accounts and no clutter. You plan your week, then your days, and your notes stay useful after the plan is done. The idea grew into the Daydock Foundation, a student-led nonprofit that helps students stop over-planning and start doing.

Try Daydock

Chapter 4

Where it probably started

A while back, I drew a ram in Desmos, the online graphing calculator, using nothing but equations. I spent more than 60 hours teaching myself parametric functions and transformations to build it, and out of tens of thousands of entries, it became a Top 20 finalist in Desmos's international math art contest.

What stuck with me was the contrast. Art and math feel like opposites, but the same kind of math I used to draw a ram is also what people use to build AI models. It's kind of crazy how versatile a few fundamental building blocks can be, and I think that's where all of this started for me.

See the ram

Outside of building

I just really like learning things.

I'm not exaggerating. I once bought an AP Chemistry textbook to read for fun, then worked through the chapters in my free time, solving hundreds of problems because I enjoyed it. I've spent weeks studying the machine learning models data scientists use to track customer satisfaction, just to understand how they work. I read about how SaaS companies make money and how marketing actually works. If something has a structure, I want to know what it is.

If I was forced to pick a second favorite thing, it would be traveling with amazing people.

One more thing

I'm a sophomore in high school.

I know age can feel like it decides what someone is able to do, and there are plenty of opportunities I can't reach yet because of mine. I don't think that has to stop me. I believe in agency: if I want something, I can work toward it, even when it's hard. So when a door isn't open to me, I try to build one.

Thanks for reading.

Really. It means a lot that you spent some of your time getting to know me. I'm not trying to sell you anything. If something here made you want to talk, I'd love to hear from you. If not, I'm just glad you stopped by. Either way, what you do next is up to you.

raaj.r.services@gmail.com