Who is Harshit Agarwal?

Harshit Agarwal is a Fullstack Software Architect and AI Researcher based in India. He acts as Founding Engineer & Lead SDE at platforms like Famcare, shoppin', and endorphind, specializing in high-throughput backend services and deep learning systems.

What technologies does Harshit Agarwal use?

Harshit specializes in Python, FastAPI, Go, C/C++, Java, React/Next.js, Flutter, PyTorch, AWS (SageMaker, EKS, EC2), Kubernetes, Rancher, Docker, PostgreSQL, Redis, and WebSockets.

What research has Harshit published?

Harshit has published research on transformer-based NLP architectures for software vulnerability exploit prediction in NVD (AIP / Springer), and has submitted gait analysis/Parkinson's Freezing of Gait prediction research to Health and Technology.

What open-source projects has Harshit built?

Harshit is the author of gaitSetPy (a Python package for high-throughput gait time-series preprocessing and modeling) and has built custom generative video nodes for ComfyUI workflows.

Architecture Decision (Day 0)

Most people treat architecture as a day 300 problem. It's not. It's a day 0 decision — and it matters more than you think.

Some overly smart system design folks will tell you to go Golang microservices from day 1 and optimize for scale before you've even validated anything. Ignore them.

The more sane take: stick to a monolith, but make it modular. Smart service layers, clean repositories, intentional abstractions. Observability and determinism baked in from the start — Sentry error logging, Alembic migrations — these aren't nice-to-haves, they're load-bearing.

One of my current projects has 38 service modules, all wired with that intent since day 1. New devs join, they know exactly where to look. Service, repository, model. That's it.

Comparison diagram: flat monolith (the mess), modular monolith (the sweet spot, 38 modules zero confusion), and microservices day 1 (the trap, kubernetes on day 3) — **Fig. 1** — the modular monolith is the middle column. Same one codebase as the flat monolith, but with a service → repository → model layer split, so every one of the 38 modules follows the same shape.

And that matters when you're at a startup shipping 10 features a week with 100s of active bugs across the QA pipeline. Good architecture isn't a luxury — it's how you avoid 10 devs on 10 laptops fighting over the same file.

Messy codebases don't happen because people are bad engineers. They happen because architecture was an afterthought. And once you're in a place where only one person understands one service — and everyone else just creates a new service rather than touching it — that debt doesn't disappear. It compounds.

Graph showing cost to fix technical debt rising over time: cheap to fix in the fixable window before day 90, then compounding into rewrite territory by day 300 — **Fig. 2** — technical debt always gets repaid. The question is when, and at what interest rate.

The flip side kills you too. I've debugged codebases with so many abstraction layers that hitting next on the debugger 10 times still doesn't get you to actual business logic. Over-engineering is its own trap.

Satirical call stack showing 10 layers of abstraction (AbstractBaseRequestHandlerFactory, GenericRequestInterceptorDelegate, etc.) before reaching the actual createOrder() business logic — **Fig. 3** — ten clicks of "next" in the debugger before you hit any real business logic. This is what over-engineering looks like from the inside.

Somewhere in between is where the good software lives.