Skip to content
Satyam Sharma
Page progress
Four years of Python in production. Three product startups.

I build the service,then I run it.

Backend engineer working the seam between development and operations — Python and Django services, and the Linux, Docker and observability layer they actually run on.

See the workRésumésatyamsharma3524@gmail.com
Satyam Sharma.
4 yrsPython and Django in production
168Ksearch impressions since Nov 2025, moneydock.in
272tests gating every production deploy
9containerised services I run myself

Software Engineer at HT Media, previously India IVF Fertility and InstaAstro. Outside work I built MoneyDock, a personal-finance platform for the Indian market: 27 calculators, ~4,800 indexed pages, five live data feeds, and 272 automated tests wired into the build command so a failing test blocks the deploy. And Animatrixx — plus the nine-container stack behind it: Django under uWSGI behind nginx, Celery on RabbitMQ, Redis, Elasticsearch, and a Prometheus/Grafana/Loki layer I self-host rather than rent.

Availability

Open to Backend, Platform and DevOps engineering roles · Delhi NCR — Noida, Gurugram · On-site, hybrid or remote

Backend

  • Python
  • Django
  • Django REST Framework
  • Celery
  • REST APIs
  • ORM

Data

  • PostgreSQL
  • MariaDB
  • MySQL
  • MongoDB
  • Redis
  • Elasticsearch

Platform

  • Linux
  • Docker
  • nginx
  • uWSGI
  • AWS
  • Vultr
  • CI/CD

Operate

  • Prometheus
  • Grafana
  • Loki
  • RabbitMQ
  • Vitest

01 · Now

Three things in flight

A production codebase inside a large media company, and two products I built and still operate myself — one of them serving live search traffic today.

The two products below have full write-ups — the architecture, the decisions I’d defend, the ones I got wrong, and what the numbers said afterwards.

02 · Work

Two products,built and operated

Each write-up covers the same ground: what the problem was, how the system is shaped, the decisions I would defend under questioning, the ones that turned out wrong, and what is still missing. Ordered by what is hardest to fake.

Live

MoneyDock

Visit

Solo engineer — architecture, build, data pipelines, operationsPersonal-Finance Platform · FinTech

A no-signup financial platform for Indian retail investors: 27 hand-built calculators, ~1,800 stock pages and ~3,500 mutual-fund pages computed from live NSE and AMFI feeds, and 272 automated tests wired into the build command so a failing test blocks the deploy.

  • Next.js 16 (App Router)
  • React 19
  • TypeScript (strict)
  • MongoDB
  • Mongoose
Read the case study
168KGoogle search impressions · 27 Nov 2025 – 10 Oct 2026
1,270organic clicks · same window
~4,800pages indexed · ~5,100 in the sitemap
272automated tests · a failure blocks the deploy
27financial calculators, hand-derived
5live external data feeds
Live

Animatrixx

Visit

Solo engineer — backend, infrastructure, frontendAnime & Manga Platform · Self-hosted Infrastructure

An anime streaming and manga reading platform, and the nine-container stack behind it: Django under uWSGI behind nginx, Celery on RabbitMQ, Redis, MariaDB, Elasticsearch, and a Prometheus/Grafana/Loki observability layer — self-hosted rather than rented.

  • Python 3.10
  • Django 5
  • Django REST Framework
  • Celery
  • RabbitMQ
Read the case study
Architecture

Also in the repository

Design documents

Five engineering documents in the MoneyDock repository. Not deliverables for anyone — the reasoning written down so it could be argued with later, including by me.

The case studies above describe systems I built. These describe decisions I made — including the ones I later reversed, which is the part a document is actually for. A commit history tells you what changed. It does not tell you what else was on the table.

The habit came from a specific failure. On Animatrixx I made a series of reasonable local decisions — hand the reader its images through localStorage, disable the type checker to get a build out, cache whole model instances in Redis — and eight months later I could no longer reconstruct why. Each one had a cost I had not written down, so each one had to be rediscovered.

So on MoneyDock the rationale ships with the code. The scaling blueprint records not only the page sets I built but the one I killed, and the test it failed. The hardening report numbers fourteen findings and names the test that pins each fix, so a future refactor cannot quietly undo one. The deploy checklist records what was rejected as well as what shipped — including advice I was given and decided against.

The document I would point an interviewer at is the content audit. My own automation had produced about ninety-five posts of news and stock tips that were dragging the whole domain under a scaled-content signal. The audit is the paperwork of deleting roughly eighty of them.

Methods

  • Design docs
  • Decision records
  • Failure-mode analysis
  • Release gating
  • Self-audit
  • Markdown

In the repository

Five design documents, written for a team of one

A scaling blueprint, a hardening report, an SEO strategy, a deploy checklist and a content audit. Together they are the reason I can explain a decision I made eight months ago without reconstructing it.

What each document is for

  1. Scaling blueprint

    Every programmatic page set, the one test each had to pass, and the concept killed for failing it

  2. Hardening report

    Fourteen numbered findings, each with the failure it closed and the test that pins it shut

  3. SEO strategy

    Where the real risk sits, and why volume was never the problem — undifferentiated volume was

  4. Deploy checklist

    What shipped, what was deliberately rejected, and how to read the metrics afterwards

  5. Content audit

    The case for deleting roughly 80 of 95 posts my own automation had generated

03 · Method

How I decidewhat to build

Five steps, in the order I run them. Every example is from a real codebase, and step 05 is the one that changed how I work.

  1. Model the data first

    The schema decides what the application can cheaply do, so it gets settled before any endpoint exists. On MoneyDock that meant storing five years of daily prices as capped parallel arrays on one document per security rather than three million rows — which made a full history read a single document fetch, at the cost of cross-entity history queries the product never needs.

  2. Isolate what must be correct

    Anything whose wrongness is expensive gets pulled into pure, I/O-free functions that can be tested without a network. Every financial metric on MoneyDock lives in that layer, returns null rather than NaN, and ends in a finite check. The feed parsers are split into a pure parse(text) half and a fetching half for the same reason.

  3. Assume the network is hostile

    Every outbound call gets a timeout — twelve of them on MoneyDock, from 8 to 30 seconds. Retries are differentiated by failure class rather than applied uniformly: on Animatrixx, rate limits and dropped connections back off exponentially with jitter, timeouts back off without it, and non-retryable errors bail immediately instead of burning the budget. Failure degrades to the shape the client already renders, not to a 500.

  4. Run it, and watch it

    Deployment is part of the design, not the step after it. On Animatrixx that meant nine containers on one network — nginx, uWSGI, Celery, RabbitMQ, Redis, MariaDB, Elasticsearch — with Prometheus scraping application and query metrics every four seconds and Promtail shipping logs into Loki. I built that plane rather than rent one, which is why I can now read one.

  5. Make the gate mechanical

    Discipline I have to remember is discipline I will skip. MoneyDock’s Vercel build command runs the test suite before the build, so 272 failing-or-passing tests decide whether a deployment exists at all. Before the hardening pass I wrote 100 tests against the unmodified source and got them green first, so any fix that changed behaviour would be visibly wrong rather than arguably fine.

Steps 01 through 04 are judgment, and judgment fails quietly. Step 05 is the only one that fails loudly, which is why it is the one I would not give up.

04 · Stack

What I use,and where I used it

Two of these columns are projects with full write-ups on this site; three are production codebases at employers. Hover a skill to light up where it was used.

Backend

  • Python

    • AX
    • HT
    • IVF
    • IA

  • Django

    • AX
    • HT
    • IVF
    • IA

  • Django REST Framework

    • AX
    • IVF
    • IA

  • Celery

    • AX
    • IA

  • RabbitMQ

    • AX
    • IA

  • REST API design

    • MD
    • AX
    • HT
    • IVF
    • IA

  • Object-Relational Mapping

    • AX
    • IVF
    • IA

  • ETL / data pipelines

    • MD
    • AX
    • IVF

  • Web scraping

    • MD
    • AX

  • System architecture

    • MD
    • AX

  • Debugging

    • MD
    • AX
    • HT
    • IVF
    • IA

The MoneyDock column is empty for Django and Celery on purpose — that project is Next.js and cron route handlers, not Python. Claiming it there would make every other mark in this matrix worth less.

Data

  • MariaDB / MySQL

    • AX
    • IVF
    • IA

  • PostgreSQL

    • HT
    • IVF
    • IA

  • MongoDB

    • MD

  • Redis

    • AX
    • IA

  • Elasticsearch

    • AX

  • Database design

    • MD
    • AX
    • IVF

  • Database administration

    • AX
    • IVF

  • Time-series modelling

    • MD

  • Caching strategy

    • MD
    • AX

Platform & operations

  • Linux

    • AX
    • HT
    • IVF
    • IA

  • Docker

    • AX
    • IVF
    • IA

  • nginx

    • AX
    • IVF

  • uWSGI

    • AX

  • AWS

    • MD
    • AX
    • HT
    • IVF

  • Vultr

    • AX
    • IVF

  • CI/CD

    • MD
    • AX
    • IVF

  • System deployment

    • MD
    • AX
    • IVF

  • Prometheus

    • AX
    • IA

  • Grafana

    • AX
    • IA

  • Loki / log shipping

    • AX

  • Kubernetes

    • Not yet attributed

Kubernetes has no mark in any column. It is on my LinkedIn and it is not yet in anything I have shipped, so it gets an empty row rather than a generous one.

Product surface

  • Next.js

    • MD
    • AX

  • React

    • MD
    • AX

  • TypeScript

    • MD
    • AX

  • Tailwind CSS

    • MD
    • AX

  • Vitest / Testing Library

    • MD

  • Programmatic SEO

    • MD

  • Structured data (JSON-LD)

    • MD

  • Git

    • MD
    • AX
    • HT
    • IVF
    • IA
Verifiable in that codebase or role
In my toolkit — not attributed there
Not used

MD MoneyDock · AX Animatrixx · HT HT Media · IVF India IVF Fertility · IA InstaAstro

The empty cells are the point. A matrix where every row is full is a list of words, not evidence — so Kubernetes has no marks, and Django has none under MoneyDock.

Testing & correctness

In shipped work

272 tests gating every deploy
MoneyDock — in the build command
Unit-tested financial mathematics
MoneyDock — pure, I/O-free modules
Regression tests pinning each hardening fix
MoneyDock — 14 findings
Content-quality assertions as tests
MoneyDock — body length, FAQ counts

Practices I apply, not yet all in one codebase

  • Vitest
  • Testing Library
  • jsdom
  • Contract tests for API routes
  • Pure-function extraction
  • Fail-open vs fail-closed defaults
  • Timeouts on all outbound I/O
  • Graceful degradation contracts
  • Idempotent ETL
  • Backoff with jitter

Tools

Prometheus + Grafana
Animatrixx, InstaAstro
Loki + Promtail
Animatrixx
Docker Compose
Animatrixx
Google Search Console
MoneyDock
Vitest
MoneyDock
Kubernetes
Not yet shipped

Nothing on this list is here because it looks good on a list. Three of these I learned because a system I had already shipped broke without them.

About

I’m a backend engineer four years into production Python, and I’ve spent most of that time on the side of the line most teams put a handoff on.

The pattern is consistent across three startups and two solo products: write the service, model the data, then own the machine it runs on. At InstaAstro that meant Django and Celery alongside Grafana and Prometheus. At India IVF it meant the Django work and the DevOps work being the same job description. On Animatrixx it meant standing up nine containers and a metrics plane because there was nobody to ask for one. On MoneyDock it meant five ingestion pipelines, 272 tests, and being the person who has to read Search Console at midnight when indexation moves.

I’m not a developer who has heard of Docker, and I’m not an ops engineer who scripts a bit. I do both, and the reason I keep doing both is that the code gets better when you’re the one who has to keep it alive.

Journey

  1. 2022 — Python, in production, immediately.

    InstaAstro was a live consumer product and I was writing Django against it in my first year out. Two years and three months there taught me the difference between code that works and code that works at 9pm on a Sunday — and it’s where Celery, RabbitMQ, Prometheus and Grafana stopped being résumé words and became things I’d actually debugged.

  2. 2025 — The title said Django and DevOps.

    At India IVF Fertility the two halves were formally one role. That year is when I stopped thinking of deployment as the last step of development and started thinking of the runtime as part of the design — because I was the one configuring nginx, the containers and the servers underneath what I’d just written.

  3. 2024 — 2025 — Building the layer I’d always been handed.

    Animatrixx is where I self-hosted everything on purpose: Django under uWSGI behind nginx, Celery on RabbitMQ, Redis, Elasticsearch, and a Prometheus, Loki and Grafana stack I stood up myself. It also has no tests, secrets I baked into a Docker image, and a homepage rail that silently returns nothing. I learned more from that list than from anything that went right.

  4. 2026 — Doing it properly the second time.

    MoneyDock is the correction. 272 tests wired into the build command so a failure blocks the deploy rather than filing a ticket. Timeouts on all twelve outbound calls. A hardening pass with fourteen findings, each pinned by a test written against the unmodified source first. Every one of those disciplines exists because Animatrixx showed me what its absence costs.

Current focus

What I’m working on right now: MoneyDock’s indexation curve. Impressions went from roughly a thousand a day to a peak near five and a half thousand across July, which is mass indexation at deep positions rather than a ranking win — new pages enter around position 70 and drag the average down while nothing that was ranking has moved. The work is turning that volume into position: pruning genuinely thin pages, and making sure every page still standing has a computed number on it that exists nowhere else.

What I’m getting better at: Instrumenting features rather than infrastructure. I had a four-second scrape interval on request rates and no way to notice that an entire homepage rail had been returning an empty list for weeks. Uptime and correctness are two different questions and I was only asking one of them.

What I’m looking for: A backend or platform role where owning the runtime is part of the job rather than another team’s. Python and Django services, real data volume, and infrastructure I’m expected to understand rather than file tickets against. I’d rather be somewhere the on-call rotation includes the people who wrote the code.

Based in Noida, Uttar Pradesh. MCA, IGNOU, 2025.

05 · Background

Experience, education,credentials

The formal version, for anyone who needs it in this shape.

  1. Software Engineer

    HT Media · Hindustan Times

    Gurugram, Haryana · On-site

    • Backend and infrastructure engineering inside one of India’s largest media groups — an established codebase, architectural decisions I did not make, and traffic at a scale no side project reaches.
    • Python, Django and Linux server work, in an environment where the development and operations halves of a change are both mine to reason about.

  2. Software Engineer (Django, DevOps)

    India IVF Fertility

    Noida, Uttar Pradesh · On-site · 1 yr 2 mos

    • A role where the Django work and the DevOps work were formally the same job: building Django and Django REST Framework services, and configuring the containers, servers and deployment path they ran on.
    • MariaDB schema design and administration, deployment pipelines, and system deployment — the areas colleagues at the company have since endorsed on the public record.
    • This is the year deployment stopped being the step after development for me and became part of the design, because I was the person underneath what I had just written.

  3. Software Engineer (Python, Django)

    InstaAstro

    Noida, Uttar Pradesh · On-site · 2 yrs 3 mos

    • Back-end engineering on a live consumer product at a product-based startup — Python, Django and Django REST Framework against real users from my first year in the industry.
    • Asynchronous processing with Celery over RabbitMQ, MariaDB and ORM-level work, and Docker on Linux for packaging and deployment.
    • Where Prometheus and Grafana stopped being résumé entries and became tools I had actually debugged a production problem with — the reason I later chose to build that layer myself rather than rent it.

  4. Data Science & Machine Learning Apprentice

    Coding Ninjas

    Apprenticeship · 1 yr 3 mos

    • Structured apprenticeship in data science and machine learning, run alongside full-time engineering work. The Python data-handling habits it built are the ones the MoneyDock metric layer is written with.

Education

MCA, Computer Software Engineering

Indira Gandhi National Open University

Jul 2023 — Jul 2025

Completed while working full-time as a software engineer — the master’s ran alongside two and a half years of production work rather than before it. Earlier: BCA in web and software development from Panjab University, Chandigarh (2019–2022), graduating with an A+ grade.

Certifications

Data Structures & Algorithms in Python — Excellence Certificate
Coding Ninjas · Nov 2022
Python — Certificate of Excellence
Coding Ninjas
Django — Skill Assessment, passed
LinkedIn
Data Science & Machine Learning
Coding Ninjas

Achievements

Drawn from work that exists and can be checked. Every figure carries the window it was measured over; the search numbers are Google Search Console for moneydock.in, 27 November 2025 to 10 October 2026, web search.

168,000

search impressions since November 2025

moneydock.in, from a domain with no search history before late November 2025

4,800+

pages indexed by Google

Programmatic page sets built to survive a scaled-content review

272

tests gating every production deploy

Grown from 100. In the build command, so a failure blocks the deployment

2,300

API calls replaced by a single CSV

Switching to NSE's official Bhavcopy removed the rate-limit ceiling entirely

9

services self-hosted and administered

Animatrixx — including the Prometheus, Grafana and Loki plane I built myself

4

years of production Python

Across three product-based startups, none with a separate ops function

Ownership

Owning the runtime, not just the commit.

Across three employers and two solo products, the operational half has never been someone else’s. That is why I configure nginx and uWSGI, why I stood up a metrics and log-shipping plane on Animatrixx rather than requesting one, and why I treat a deployment path as something to design instead of something to follow.

Making my own discipline mechanical.

MoneyDock’s test suite lives in the build command rather than in CI, because a green badge is advisory and a build that refuses to produce a deployment is a constraint. Before the hardening pass I locked existing behaviour behind 100 tests written against untouched source, so any fix that changed something would be visibly wrong rather than arguably fine.

Publishing my own defects.

The Animatrixx write-up on this site names the secrets baked into a Docker image, the homepage rail that silently returns nothing, and the localStorage decision I would reverse. I would rather be the engineer who found those and said so than the one who shipped them and hoped nobody looked.

06 · Contact

Let’s talk

I’m looking for a backend or platform engineering role — Python and Django services, real data volume, and infrastructure I’m expected to understand rather than file tickets against.

If you’re hiring for something like that, or you want to argue with a decision in one of the case studies above, email is the fastest way to reach me. The Animatrixx write-up has a list of my own mistakes in it; I’m happy to go deeper on any of them.

satyamsharma3524@gmail.com
Email meConnect on LinkedInRésuméMoneyDock

Direct

Location
Noida, Uttar Pradesh, India · IST (GMT+5:30)
Availability
Open to Backend / Platform / DevOps roles
Work setup
On-site, hybrid or remote · Delhi NCR
Experience
4 years in production