2026.08.25 · WRITING

Why I Built Made by Arjun

A personal site can show the engineering judgment that a list of technologies leaves out.

Programmers are easily reduced to a handful of keywords.

Python, backend systems, AI agents, RAG, Docker. These terms can appear on any résumé, but they say very little about the problems someone has actually solved or the engineering judgment behind those decisions.

Made by Arjun exists to cover what the keywords leave out.

Work says more than labels

“Familiar with a technology” is a vague description.

A working project reveals something more concrete: where the system boundaries sit, how failure is handled, why one architecture was chosen, and what was left out when resources were limited.

Code can prove that a feature was built. Writing can explain the judgment behind it.

I want to put those two things together.

GitHub holds the projects themselves. This site records the questions, choices, and reasoning behind them. Together, they form a more complete technical record than a conventional résumé.

Calling the model is rarely the hard part

An AI application producing an output does not make it a reliable system.

Beyond the model, there is data, queues, caching, permissions, logging, quality evaluation, and failure recovery. A prototype can depend on one successful demo. A real product has to handle repeated runs, unexpected inputs, and long-term maintenance.

That gap is where I focus:

Turning model capabilities into engineering systems that run reliably.

This site will not stop at explaining how to call a particular framework, nor will it chase every idea that suddenly becomes popular. I want to examine what happens when technology enters a real project: which problems it solves and which new complexities it creates.

Writing in public is engineering practice

Many personal projects stop at “it runs.”

The code has little documentation, the architecture depends on memory, and the deployment cannot be reproduced. A few months later, even the developer may struggle to understand it again.

Writing forces me to revisit those problems.

When a technical decision has to be explained clearly, vague reasoning becomes visible. When someone else needs to run a project, overlooked edge cases surface too.

Writing is not promotional work that begins after a project is finished. It is part of the engineering process.

A personal site creates long-term ownership

Social platforms are useful for distribution, and code platforms are useful for collaboration, but neither fully replaces a space of your own.

A personal site does not depend on a feed to decide what deserves to remain. Its content does not need to conform to a platform’s preferred format. A domain can connect projects, writing, and a public identity over time, allowing every new piece of work to accumulate in one place.

Made by Arjun is not another content account. It is a space on the internet that I intend to maintain.

What belongs here

The site will primarily cover three areas:

• how AI applications move from prototypes to systems;
• practical problems in backend architecture, deployment, and operations;
• engineering decisions involved in taking independent products from idea to launch.

The articles will not show only the parts that went well.

Bad calls, failed approaches, and discarded designs are worth documenting too. They may not form a polished success story, but they are closer to how software development actually happens.

Keep building rather than present it as finished

Made by Arjun is not trying to create the image of someone who knows everything about technology.

It is closer to a public workbench that keeps evolving: projects are taken apart, ideas are organized, and unresolved questions are allowed to remain visible.

Job titles may change, and tools and models will keep evolving. The ability to solve problems, build complete systems, and explain the work clearly can keep growing.

That is why I built Made by Arjun.