# RK / In Motion — Rajesh Kumar

> Python backend developer based in Coimbatore, Tamil Nadu, India. Builds APIs, backend services, and full-stack applications with Python, Django, FastAPI, PostgreSQL, React, and Next.js.

Rajesh develops independent projects and live applications, growing through hands-on work across APIs, interfaces, data, and deployment. Professional experience strengthens this foundation alongside continuing studies in AI and machine learning.

## Profile and contact

- [About](https://www.rajeshkumarg.com/about)
- [Contact](https://www.rajeshkumarg.com/contact)
- [Work and case studies](https://www.rajeshkumarg.com/work)
- [GitHub](https://github.com/Rajeshkumarg-14)
- [Resume](https://www.rajeshkumarg.com/pdfs/Rajesh_Kumar_G_Resume.pdf)
- Email: rajeshkumarg.dev@gmail.com

## Production project case studies

Project names are public aliases. Usage status is owner-confirmed; no private owner names, source code, deployment URLs, or precise user counts are disclosed. Artwork is conceptual.

### Stride

[Case study](https://www.rajeshkumarg.com/work/stride)

A connected platform for competency tracks, assessments, student progression, staff coverage, and hackathon operations.

**Status:** Live · used by many users

**Stack:** Next.js, FastAPI, PostgreSQL, SQLAlchemy, Redis, Celery, S3 storage

**Architecture:** People & assessments → Scoped FastAPI services → PostgreSQL & workers

**Capabilities:**
- Track and level progression with recorded assessment attempts.
- Student and staff directories with organizational scopes.
- Leave approval and class-cover workflows with notifications.
- Hackathon registration, submissions, check-in and results.
- Learning activity synchronization and reporting.

**Engineering decisions:**
- Separate role permissions from row-level organizational scope.
- Isolate cache and pub/sub clients so notification delivery does not block cache access.
- Separate mail, bulk processing and analytics into worker queues.

### Folio

[Case study](https://www.rajeshkumarg.com/work/folio)

Event-based certificate issuance with server rendering, signed verification, roster imports, and a student download portal.

**Status:** Live · used by many users

**Stack:** Next.js, Prisma, PostgreSQL, Redis, BullMQ, Chromium, Ed25519

**Architecture:** Roster & templates → Issuance & render queue → Signed certificate & verification

**Capabilities:**
- Event enrolment and bulk roster imports with error reporting.
- Versioned templates and an in-app layout editor.
- Server-rendered PDF and image certificates.
- QR-linked certificate verification and student downloads.
- Mailbox-based delivery scheduling and administrative audit history.

**Engineering decisions:**
- Use an event/student uniqueness constraint to prevent duplicate issuance.
- Render templates on the server for consistent output.
- Seal certificate data and verify both stored records and signatures.

### Tempo

[Case study](https://www.rajeshkumarg.com/work/tempo)

Staff scheduling, verified profiles, reviewed timetable changes, and assigned work in one operational workspace.

**Status:** Live · used by many users

**Stack:** Next.js, PostgreSQL, Prisma, ExcelJS, Web Push, Docker, Nginx

**Architecture:** Timetables & profiles → Review & task workflows → Reports & notifications

**Capabilities:**
- Weekly timetable imports and daily availability planning.
- Schedule alterations and management review.
- Task assignments, submission and verification.
- Academic profile drafts with field-by-field approval.
- Workload reporting, exports and scheduled reminders.

**Engineering decisions:**
- Keep profile changes in a private draft until they are reviewed.
- Persist notifications before attempting best-effort push delivery.
- Run reminders and mail delivery through cron and a database outbox.

### Nexus

[Case study](https://www.rajeshkumarg.com/work/nexus)

Student information and placement management with verified academic records, scoped access, and role-specific dashboards.

**Status:** Live · used by many users

**Stack:** Next.js, FastAPI, PostgreSQL, SQLAlchemy, Redis, Celery, Docker

**Architecture:** Student evidence → Verification & scoped services → Academic & placement records

**Capabilities:**
- Academic marks and attendance with proof-based review.
- Student profiles, skills, certifications and projects.
- Resume generation and placement-related records.
- Role-specific widgets and real-time dashboard updates.
- Organizationally scoped visibility and audit logging.

**Engineering decisions:**
- Represent access scope explicitly across the university hierarchy.
- Use async API and persistence layers with dedicated background workers.
- Separate uploaded evidence and generated artifacts into object storage.

### Relay

[Case study](https://www.rajeshkumarg.com/work/relay)

Company discovery, outreach, approval, and placement-drive handoffs for campus recruitment teams.

**Status:** Live · used by many users

**Stack:** React, TypeScript, Express, PostgreSQL, Redis, Socket.IO

**Architecture:** Company discovery → Outreach & approvals → Placement drives

**Capabilities:**
- Company information collection and conversion stages.
- Multi-level approvals before placement finalization.
- Role-based workflows and quotas.
- Searchable tables, reporting and team handoffs.

**Engineering decisions:**
- Separate collection, conversion and finalization stages.
- Combine shared session storage with role-based authorization.
- Coordinate client updates through real-time communication.

### Talent

[Case study](https://www.rajeshkumarg.com/work/talent)

A university recruitment pipeline with dedicated HR, candidate, and administration portals.

**Status:** Live · used by many users

**Stack:** Next.js, TypeScript, PostgreSQL, Prisma, Redis, BullMQ, Socket.IO

**Architecture:** Candidates → Recruitment pipeline → HR decisions & notifications

**Capabilities:**
- Kanban-style applicant progression.
- Separate candidate, HR and super-administrator experiences.
- Real-time notifications and bulk email workflows.
- Spreadsheet imports and exports.

**Engineering decisions:**
- Coordinate role-specific portals around one application pipeline.
- Queue email processing separately from interactive requests.
- Validate API boundaries and support refreshed authentication sessions.

### Pulse

[Case study](https://www.rajeshkumarg.com/work/pulse)

A focused student-completion workflow: QR entry, staff lookup, immediate status updates, and administrative visibility.

**Status:** Live · used by many users

**Stack:** Next.js, TypeScript, PostgreSQL, Prisma, Zod

**Architecture:** QR entry & lookup → Staff completion workflow → Status dashboard & audit

**Capabilities:**
- QR entry and authenticated roll-number search.
- Student detail and completion updates.
- Completion trends and recent activity.
- Audit history for status changes and resets.

**Engineering decisions:**
- Keep the staff workflow short enough for on-site use.
- Use signed sessions and validated service boundaries.
- Record changes so administrators can trace completion decisions.

### Altitude

[Case study](https://www.rajeshkumarg.com/work/altitude)

A cloud-training storefront connecting course exploration, enrolment payments, and confirmation workflows.

**Status:** Live · used by many users

**Stack:** React, TypeScript, Vite, Express, Razorpay, Nodemailer

**Architecture:** Course exploration → Checkout & payment verification → Enrolment & confirmation

**Capabilities:**
- Cloud certification roadmaps and course exploration.
- Individual and bulk enrolment flows.
- Payment confirmation and email notifications.
- Responsive purchase interactions and interactive visual content.

**Engineering decisions:**
- Verify payment signatures on the server.
- Connect enrolment records to payment and confirmation workflows.
- Support quantity-aware purchase flows across mobile and desktop.

### Studio

[Case study](https://www.rajeshkumarg.com/work/studio)

A responsive company website with portfolio pages, contact flows, theming, and route-level loading.

**Status:** Live · used by many users

**Stack:** React, TypeScript, Vite, React Router, Motion, Tailwind CSS

**Architecture:** Company information → Services & portfolio → Contact enquiry

**Capabilities:**
- Company and portfolio pages.
- Dark and light themes.
- Contact forms and consent controls.
- Responsive motion and page metadata.

**Engineering decisions:**
- Split route loading and animation bundles.
- Coordinate theming with view transitions.
- Preserve page metadata and responsive navigation across routes.

### Ledger

[Case study](https://www.rajeshkumarg.com/work/ledger)

GST-aware invoicing with configurable document templates, bulk spreadsheet input, and server-generated PDFs.

**Status:** Live · used by many users

**Stack:** React, Vite, Express, Prisma, PostgreSQL, Puppeteer

**Architecture:** Clients & line items → Tax & template configuration → Rendered invoice PDF

**Capabilities:**
- Line-level GST, discounts, tax codes and round-off.
- Customizable invoice layouts and branding.
- Bulk invoice generation from spreadsheets.
- Client records and staff permissions.

**Engineering decisions:**
- Generate PDFs in a dedicated headless-browser service.
- Store template configuration as native JSON.
- Normalize API errors and separate frontend generation progress from server rendering.

### Atlas

[Case study](https://www.rajeshkumarg.com/work/atlas)

An API-first learning platform with shared product rules, background processing, and protected media delivery.

**Status:** In development

**Stack:** Next.js, FastAPI, PostgreSQL, SQLAlchemy, Redis, RabbitMQ, Celery, MinIO

**Architecture:** Learning clients → Shared API & workers → Learning data & media

**Capabilities:**
- A shared API contract for web and future mobile clients.
- Dedicated payment, mail, video, file and bulk workers.
- Object-storage media and HLS processing.
- Deployment health checks and rollback tooling.

**Engineering decisions:**
- Keep product rules in FastAPI instead of duplicating them in clients.
- Separate queue workloads by operational responsibility.
- Gate HLS playback and maintain a documented restore workflow.

### Seal

[Case study](https://www.rajeshkumarg.com/work/seal)

Event-based certificate generation with public requests, server rendering, and signed QR verification.

**Status:** In development

**Stack:** Next.js, Prisma, PostgreSQL, Redis, BullMQ, Chromium, Ed25519

**Architecture:** Event enrolment → Queued issuance & rendering → Certificate verification

**Capabilities:**
- Event rosters and public certificate requests.
- Template publishing, preview and revocation.
- Server-rendered certificate documents.
- Signature verification and administrative audit history.

**Engineering decisions:**
- Prevent duplicate issuance with database constraints.
- Process certificate rendering through a background queue.
- Separate public verification from administrator-only operations.

## Earlier projects

- [Library Management System](https://www.rajeshkumarg.com/work/library-management-system): A comprehensive library management system leveraging JWT-based authentication and modern web technologies for seamless book management and user interaction.
- [Medical Leaf Recognition](https://www.rajeshkumarg.com/work/medical-leaf-recognition): A machine learning-powered system combining CNNs and Django to identify medicinal leaves and provide detailed descriptions and remedies.
- [Ticket Booking System](https://www.rajeshkumarg.com/work/ticket-booking-system): A comprehensive web application for booking tickets for flights, trains, and buses with a user-friendly interface.
- [Cafe Management System](https://www.rajeshkumarg.com/work/cafe-management-system): A Django-based web application for managing cafe operations, including order management, database storage, and daily order reporting.
- [E-Commerce Site Template](https://www.rajeshkumarg.com/work/e-commerce-site-template): A responsive e-commerce site template designed to enhance online stores with modern web technologies and a user-friendly interface.
- [Twitter Sentimental Analysis](https://www.rajeshkumarg.com/work/twitter-sentimental-analysis): A machine learning project implementing sentiment analysis on Twitter data using NLP techniques to classify sentiments accurately.

## Writing

- [3,488 contributions later, my laptop and I need to talk](https://www.rajeshkumarg.com/blog/3488-contributions-later)

## Patent publication

Universal Autonomous Cognitive Engineering Intelligence Platform (UACEIP): A Quantum-Neuro-Symbolic Self-Evolving Digital Twin Architecture for Cross-Domain Engineering, Scientific Research, Industrial Automation, and Sustainable Smart Infrastructure

Rajesh Kumar G is a co-inventor. Application 202641087385; filed 2026-07-17; published 2026-07-24 in the Indian Patent Journal. Status: Published application. Field: Computer Science. Publication details supplied by the owner.

Inventors: Dr. S. Vanitha, Dr. T. Papitha Christobel, Radhika K. Manjusha, S. Oyyathevan, Virag Shaileshkumar Shah, Arun Haydn Rundeepkumar D, Dharshini D. R, Rajesh Kumar G.

[Official journal index](https://search.ipindia.gov.in/IPOJournal/Journal/patent)

## 3,488 contributions later, my laptop and I need to talk

A year of building with Python, FastAPI and Next.js: overheating laptops, port conflicts, VPS deployments, and learning to work with AI without handing over the decisions.

Published: 2026-10-11

### “Just one more project” is not a harmless sentence

When I first drafted this story for LinkedIn, my GitHub profile showed 2,890 contributions. By 11 October 2026, that number had reached 3,488 over the previous year. Somewhere along the way, my laptop started asking for a meeting.

This year I kept building, learning, breaking things, and fixing them. Some projects worked. Some needed another attempt. Occasionally, a deployment made me question every decision that had led me there.

My usual stack was Python and FastAPI, Next.js, PostgreSQL, Docker, Redis, and Celery. Each new project gave me another reason to understand how those pieces connect. It also gave my laptop another reason to turn on its fans.

### My laptop discovered it had feelings

Running several full-stack projects together sounded reasonable. Then the CPU got hot, the RAM disappeared, and the fans started preparing for take-off. My contribution to the situation was saying, “It’s fine.” It was not fine.

Even with 24 GB of RAM, I eventually met the blue screen of death. At one point, I actually put my chips behind the laptop exhaust to keep them crispy. If the laptop was becoming an oven, I thought it could at least contribute to lunch.

The joke was funny. The friction was real. Building an application and running several applications together turned out to be different problems. I was learning about the environment around my code as much as the code itself.

### Port already in use: the unofficial soundtrack

Port 3000 was taken. Port 3001 was taken. Port 3002 was somehow also taken. I spent far too much time changing ports, mapping ports, and restarting containers.

A frontend, an API, a database, and background workers are manageable individually. Put several versions of them on one machine and the boundaries start to matter: which process owns a port, which service talks to which address, and what is still running after I think I have stopped it.

It was an unglamorous lesson, but a useful one. “I’ll sort out the environment later” has a way of becoming the entire afternoon.

### Localhost agreed. The VPS did not

Then came the classic developer experience: everything worked on localhost. I deployed it to a VPS, and the server responded with the technical equivalent of “Absolutely not.”

When I started, I barely knew what a VPS or cloud server was. Now, deploying to VPS machines and working with Docker, networking, reverse proxies, and production infrastructure are regular parts of how I build.

That changed the questions I asked. It was no longer enough to know that a feature worked on my machine. I had to understand how the application would run somewhere else, and why that environment behaved differently.

My mindset moved from “What if I break production?” toward “If something breaks, we can understand it and fix it.” The confidence is in learning to diagnose a problem and taking responsibility for the fix. The dramatic version still sounds better as a meme.

### AI joined the team. We immediately had disagreements

At first, I thought I should write everything myself. Then Claude Code, Codex, and Antigravity became part of my workflow. Claude Code started feeling less like a tool and more like a coworker.

I guided the workflow; it helped with the code. When the tokens ran out, I went back to coding manually, fixing mistakes, and waiting for the limit to reset.

The funniest moments came when an assistant returned, decided my changes looked like an older version, and removed a fix. My response was usually: “That was my fix. If it was unnecessary, why did you write the original version?”

Sometimes I found myself asking whether it was daydreaming while working. Apparently, arguing with a coworker now includes arguing with a language model.

### Faster output still needs someone to make the decisions

Working with AI has made one thing clearer to me: getting code quickly and knowing what should change are separate skills. I still need to understand the problem, review the result, and decide whether the proposed fix belongs in the project.

The useful part is having help while I explore unfamiliar tools or work through an implementation. The frustrating part is when a confident answer misses context, introduces a mistake, or rewrites something that already solved the problem.

I am still figuring out that balance. AI is part of my workflow now, but understanding the application cannot become somebody else’s job.

### The number records activity. The projects tell the story

Those 3,488 contributions are a record of activity, not a score for code quality. What matters more to me is the work behind them: projects that became real applications, unfamiliar technologies that became useful tools, and problems I can now approach with more confidence.

Not every day was productive. Not every project worked. Not every deployment went smoothly. But I kept coming back, trying again, and learning from the result.

A year ago, I was asking what a VPS was. Today, I am deploying applications and thinking about how their interfaces, services, data, and infrastructure fit together. That is the growth I want this portfolio to show.

### Still building. Hopefully not replacing the laptop

There is plenty left to learn. That is part of what keeps me interested: a new project rarely lets me stay comfortable for very long.

I am still learning, still building, and still occasionally breaking things. The laptop is still involved, although I am not sure it agreed to all of this.

And, as a Python developer, I remain attached to the joke: 3,488 contributions. Zero semicolons. I will leave the Next.js files out of that calculation.

What is one technology you learned this year that changed how you build?