README - about my Story

README

About My Story.

If you've made it this far, you've probably read about some of the things I've built.

You've read about how I started, how projects came to life, how some of them broke, and what I've learned about finishing things and putting them into the world.

But projects only tell part of the story.

They don't show the kid in Class 1 playing Minecraft who wondered, How was Minecraft built? They don't show the frustration of learning C++, the computer experiments that went wrong, or the distance between imagining something and knowing how to make it real.

They show the result, not always the person behind it.

So, here's a little more about me.

It started with a question.

When I was in Class 1, I played Minecraft. At some point, a simple question caught my attention:

How was Minecraft built?

I didn't know much about programming. I didn't understand programming languages or how software was made. I didn't even know how to search for answers the way I do now.

I started learning through YouTube. Eventually, that curiosity led me to C++.

Getting started wasn't smooth. There were setup problems, concepts I couldn't understand, and plenty of frustration. I experimented with my computer, ran into Windows problems, and explored Linux through dual booting.

I wasn't following a carefully planned roadmap toward becoming a developer. I had a question, and I wanted an answer.

That pattern still follows me. Whether I'm exploring software development, cybersecurity, or a system I don't understand, I want to know what's happening underneath.

What makes it work? Why does it fail? What am I missing?

I'm still that kid asking how things are built. I've just found more complicated things to ask questions about.

Then I started building things.

Learning to code was one thing. Making something another person could actually use was different.

One of my early projects was DAV Notes, a platform I built with my middle-school best friend to provide notes to students at our school.

For the first time, the purpose went beyond learning syntax or getting code to run. We wanted to make something that could help other students.

Later, my first client approached me to build a web application. That made the responsibility feel even more real. Someone had a problem they wanted solved, and they were trusting me to work on it.

That was when building started to feel like a responsibility, not just an experiment.

I continued creating things, sometimes because someone needed them and sometimes simply because I wanted them to exist.

But an idea and the ability to execute it are two different things. The gap between them is where much of the real work happens.

I've made mistakes that changed how I build.

One example was a workload balancer I built for my school.

The idea was to help teachers and school administrators manage workload distribution. I focused on building the functionality and getting the system working.

But I made an architectural mistake: I stored the data in the browser's local database. The information couldn't be shared between different users as the application required.

The application could work in one context and still fail to meet the larger need. I eventually addressed the issue in an update.

That experience changed how I thought about building software. Features don't exist in isolation. Data storage, architecture, and the way people interact with a system are just as important as whether individual functions work.

Code can do exactly what you tell it to do and still fail to solve the problem you built it for.

I still like moving quickly. The excitement of making an idea real is part of why I build. But I'm learning that speed without enough thought can create problems that take far longer to fix.

The goal isn't to plan every possible outcome. It's to think carefully about the decisions that matter before they become someone else's problem.

Sometimes, the idea is bigger than my skills.

I've started projects where I could picture what I wanted to build but couldn't yet figure out how to implement it.

I'd reach a point where the vision was clear, but my knowledge wasn't enough to carry it forward.

Sometimes I learned what was missing, investigated unfamiliar concepts, and found another way. Other times, I stopped working on the project.

I'm not going to pretend every unfinished project was secretly a success. Some could have been handled better. Some were abandoned. Some remain incomplete.

But they taught me to recognize the difference between a difficult problem and a problem I'm not yet equipped to solve.

That distinction matters.

A limitation can be a reason to stop, but it can also be a starting point for learning. The important thing is being honest about which situation I'm in.

The distance between what you imagine and what you can build today is a measure of what you still need to learn—not a permanent limit on what you can become.

Curiosity took me beyond building.

Eventually, my interest in technology led me toward cybersecurity.

I didn't want to understand only how systems were created. I wanted to understand how they behaved under pressure, where they failed, and why something that appeared to work could still contain weaknesses.

My questions changed. I started looking beyond what an application was designed to do and thinking about its assumptions, its components, and the ways those components interacted.

That curiosity continues in CORVEX, my security and attack-chain finding tool.

I've spent time refining it because I want it to be useful, not merely something that exists in a repository. I want to improve how it helps identify and understand security issues before releasing it.

But CORVEX has also made me confront a familiar challenge: knowing when more refinement is necessary and when it becomes a reason to delay.

I want to build ambitious things, but ambition doesn't automatically provide the knowledge required to build them well.

Sometimes the next step isn't writing more code. It's understanding the problem more deeply.

I've learned that being good at technology isn't about having every answer. It's about knowing how to investigate the questions you can't answer yet.

Ambition comes with a contradiction.

I want to achieve big things.

I want to build things that matter, create opportunities for myself, and become someone my family and the people close to me can be proud of. Independence has always been important to me, and that ambition pushes me to keep learning.

But the more I learn, the more I realize how much I don't know.

When I first started coding, I could imagine building almost anything. I didn't yet understand everything involved in making software reliable, maintainable, secure, and genuinely useful.

Now, every project reveals another layer: architecture, design, performance, security, user experience, and decisions I didn't even know I needed to consider.

That realization can be overwhelming, but it also keeps the journey interesting.

I can want more for myself without pretending I'm already where I want to be.

I can be proud of my progress without confusing it with completion.

Building is one thing. Shipping is another.

I've built and deployed websites and applications, including my portfolio, Edurify, and earlier versions of Arvexa and Rahi.

Each project taught me something about turning an idea into something people can actually visit or use. But I've also learned that putting something online doesn't automatically make it finished.

A project needs to serve its purpose. People should be able to use it without unnecessary difficulty. Its architecture should support what it needs to do. And its quality should match the responsibility I'm asking others to place in it.

With CORVEX, I'm still working through those questions.

I don't think every experiment needs to meet the same standard as a product someone depends on. But I do think the standard should rise with the responsibility.

Don't demand production-level perfection from an experiment. Don't deliver experiment-level quality to someone who depends on your product.

I'm still learning when to refine, when to release, and when to accept that the next version will be better because real people have finally had the chance to use the current one.

This website is part of the story.

I could have made this website a straightforward list of projects, technologies, and achievements.

There would be nothing wrong with that. A portfolio should show what you can do.

But I wanted mine to do something more.

I wanted a place to document not just what I built, but why I started, what went wrong, what I learned, and how those experiences changed the way I think.

Because a repository can explain how to install a project. Documentation can describe its architecture. A portfolio can show you the finished result.

None of those things necessarily tells you what it felt like to build it.

This website brings those pieces together: the work, the learning, the failures, the ideas, and the experiences that don't fit neatly into a project description.

I don't want it to make the journey look easier than it was. I want it to record the journey honestly, including the parts that are still unfinished.

So, take a look around.

If you're here for the work, start with Selected Work and explore the projects I've built. Follow the links, look at the code where it's available, and see what I've been experimenting with.

If you're interested in how I think, head to the blog. The articles follow my journey from early curiosity to building software, learning from broken projects, exploring cybersecurity, and figuring out what comes next.

And if you're interested in the person behind the work, keep reading. Not every part of a life fits into a GitHub repository.

You might find a project that interests you, an idea that makes you think, or a mistake that saves you from making the same one.

That's enough of a reason to explore.

I'm not finished. I'm just getting somewhere.

I don't know exactly where I'll end up.

I have goals, ideas I want to build, skills I want to develop, and problems I want to understand. Some ambitions will change. Some projects won't work out. Others may take me somewhere I can't imagine yet.

But I don't need to know the entire story to keep writing it.

Years from now, I hope I can look back at this version of myself and see how much I've learned—not just from the things that worked, but from the things that forced me to think differently.

I hope I remember the kid who wondered how Minecraft was built, the projects that taught me what software development actually demands, and the curiosity that kept pushing me toward the next question.

For now, I'm still learning, still building, and still figuring things out.

This isn't a story about someone who has made it.

It's a record of someone working toward something, one question and one project at a time.

I'm not here to show you a finished version of myself. I'm here to show you the process of becoming one.