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.

Feature Flags & Rollout Strategy

Sat down with Dr. Stone S4 running, deep in thought about a startup's analytics data I just revamped. Pasted it into Claude Code and started asking the obvious question: what tech gaps does this expose?

Two things became very clear very fast.

Feature Flags Beyond AB Testing

Internally we've been using them for dev checks. But with a growing team, no one really thinks about dark rollouts. So I dug in. Quickly realised this pattern isn't limited to AB testing. You can use feature flags and roll out toggles for so much more: circuit breakers, gradual migration, safety nets on database changes, everything.

And then I found out Meta's been doing this forever. Some smart consultant would probably tell you to go LaunchDarkly or Firebase immediately, which might not be the best call for a startup. Sometimes a basic single table and better developer practice is enough. All hail DLCs.

Flowchart of feature flag decision logic: user request checks if the flag is enabled, then checks rollout percentage via hash(user_id), routing to old code or new code accordingly — **Fig. 1** — the actual decision path behind a feature flag check. Same logic whether you're using LaunchDarkly or a single table.

Feature Rollout Strategies

What fast moving consumer startups forget is that features aren't slowed down by planning, they're slowed down by instability. I shipped a feature plan today, refined with real production data. Made a little CLI tool for the team to engage with before rolling anything out. Canary deployments to 10 users, then 20%, then full.

users in the initial canary stage

20%

rollout before going full

100%

final rollout stage

Flag off

→

10 users

→

20% rollout

→

100%

Fig. 2 — canary rollout stages. Each stage is a gate, not a timer — promotion only happens once the prior stage is clean.

Good software isn't about writing code fast and shipping fast. It's about writing good code that gets tested by a thousand real users before the first bug makes it to production.

Speed without discipline just gets you to broken faster.