I recently gave my developer portfolio a major update. I’m still iterating on it and improving things as I go, but I thought I’d share it now and get some feedback from others.
👉 Portfolio: https://keshavkjha.com
After 7+ years of building software, I realized my old way of presenting myself had a problem.
Like many developer portfolios, it was easy to focus on things like:
React. Go. Python. Node.js. PostgreSQL. Kubernetes. AWS. Docker.
Those things matter.
But they don't really explain what I do.
A technology list doesn't show whether someone can take an unclear product idea, make technical decisions, build the system, ship it, debug the uncomfortable parts, deploy it, and continue owning it when real users arrive.
That's what I wanted the new portfolio to communicate.
From "here are my skills" to "here is what I built"
Most of my career has been product-oriented.
I've worked on products ranging from fintech and logistics to SaaS, internal business systems, ecommerce, AI workflows, APIs, infrastructure, and customer-facing applications.
So instead of making the portfolio primarily about technologies, I reorganized it around actual work and engineering ownership.
The new version currently includes 12 case studies.
Some examples:
Visionboarder
A social vision-board product where my work extends across the customer application, admin tooling, backend systems, AI features and workflows using open-source AI models, media processing, databases, infrastructure, and deployment.
That includes models and systems around LTX-2.3, LTX-2.5, FLUX.1, FLUX.2, Z-Image Turbo, content moderation, NSFW detection, image/video generation, and related workflows.
The wider stack includes things like Next.js, React, TypeScript, Go, Python, RabbitMQ, Redis, PostgreSQL, serverless AI model deployment on RunPod, Docker, Kubernetes, and CI/CD.
But the interesting part isn't really the stack.
It is owning the path from a product requirement all the way to a production system.
Kotak Gateway / Kotak Neo
I worked on SDK and API-driven experiences for integrating investment and trading journeys into other products.
This kind of work taught me a lot about building software where your own application isn't the only thing that matters.
The integration experience, API contracts, reliability, communication between teams, backward compatibility, and developer experience become part of the product too.
SITA Operations Platform
An internal product that helped move operational work away from spreadsheet-based coordination and into a proper application.
Not every valuable engineering problem needs a new AI model or a complicated distributed architecture.
Sometimes the most valuable system is the one that removes an inefficient workflow people have tolerated for years.
EasyGlobalShip
A shipping platform for Indian ecommerce sellers covering areas such as rates, shipment booking, labels, customs documentation, and tracking.
This was one of the projects that reinforced something I still strongly believe:
Understanding the business problem often matters more than choosing an impressive technology.
And there are several other projects covering contract management, hospitality, workspace booking, internal audit systems, ecommerce, and different stages of my engineering journey.
My stack became wider because the problems became wider
I started my career much closer to traditional web development.
PHP. WordPress. Laravel. JavaScript.
Then the problems changed.
Frontend applications became more complex.
I moved deeper into React and TypeScript.
Backend requirements pushed me further into Node.js and Go.
AI products brought Python and model-serving workflows into the picture.
Running those systems meant working more seriously with PostgreSQL, Redis, queues like RabbitMQ and Kafka, Docker, Kubernetes, OpenTofu, CI/CD, observability, and infrastructure.
At some point I stopped thinking of myself primarily as a developer for a particular framework.
The question became:
What does this product need in order to work well?
Sometimes that's a React interface.
Sometimes it's a Go service.
Sometimes it's a Python worker running an AI model.
Sometimes it's redesigning the database.
Sometimes it's fixing the deployment system.
And sometimes the correct answer is removing complexity rather than adding another service.
One thing AI has changed for me
The last couple of years have obviously changed software development.
For the past few months, I've been using AI much more heavily throughout my development workflow. Before that, I mostly used it for smaller fixes, research, and occasional assistance.
But I don't think the interesting part is simply generating more code.
The bigger advantage is shortening the distance between:
idea → exploration → documentation / product standards → specs → implementation → validation → iteration
AI can help investigate a codebase, generate repetitive implementation work, compare approaches, write tests, search for edge cases, review assumptions, and even challenge decisions.
That gives me more room to think about architecture, product behaviour, failure modes, trade-offs, and the decisions that are difficult to automate.
I still think engineering judgment becomes more important in an AI-assisted development environment, not less.
Generating 5,000 lines of code is becoming cheap.
Knowing whether those 5,000 lines should exist is still valuable.
What I wanted this portfolio to show
I didn't want the new site to say:
Here are 30 technologies I know. Please hire me.
I wanted someone looking through it to understand how I actually work.
Can I enter an existing product and understand it?
Can I take ownership of something ambiguous?
Can I work across frontend and backend?
Can I build an API rather than only consume one?
Can I deal with infrastructure and deployment?
Can I integrate AI without turning the whole architecture into an AI demo?
Can I work directly with founders, product owners, and engineering teams?
Can I take something from an idea to production?
Those are much more useful questions than whether I have used Framework X for exactly four or six years.
I'm also open to the right next project
I'm currently open to remote opportunities and engineering engagements.
That can mean a focused contract, a longer-term product engagement, or the right senior full-stack / product engineering role.
I'm particularly interested in work involving:
- building or scaling products
- backend and distributed systems
- Go, Python, TypeScript, and React
- AI-enabled products and workflows
- APIs and integrations
- ecommerce and commerce infrastructure
- developer tooling and internal systems
- infrastructure, CI/CD, and production engineering
- products where I can own a meaningful outcome rather than just close isolated tickets
I'm based in India and comfortable working with distributed teams across time zones.
But I'm not trying to optimize purely for finding any available work.
I'm much more interested in finding products where engineering has a meaningful impact on what gets built and where ownership is valued.
If you're building something interesting, need another experienced engineer on an existing system, or simply want to compare notes on product engineering, feel free to reach out.
Top comments (2)
SITA 사례처럼 스프레드시트에서 어떤 업무 흐름을 옮겼는지 보여주는 편이 기술 목록보다 이해하기 쉽네요. 각 사례에 이전 방식, 본인이 맡은 결정, 바뀐 운영 흐름을 나란히 넣으면 책임 범위가 더 선명해질 것 같습니다. 팀 전체의 결과와 직접 맡은 부분도 구분해서 보여주실 계획인가요?
Some comments may only be visible to logged-in visitors. Sign in to view all comments.