Software EngineerOpen to roles · Pune, IN

Anushka
Ughade

I build the production systems businesses actually run on. Full-stack, automation and AI.

Hire me →See the work

anushka@portfolio ~ zsh↑ move your cursor over me / 01[ _ ]

$ ▍

15,000+

tickets sold in one 5-day live event

1,000+

AI assets generated for 50+ client projects

100+

stores on platforms I revamped

20+

business & client websites shipped

01 / Selected work

Ship.

Systems in production, not demos. Real traffic, real clients, real consequences when they break.

01Shipped · re-platformed 2026P-01

TicketAdda

A high-traffic event ticketing platform that sold 15,000+ tickets over a single 5-day live event, re-platformed in 2026 as containerised services on Kubernetes (AWS).

15,000+: tickets sold in a single 5-day live event

ticketadda — admin walkthrough▶

01Payment confirmed (verified, idempotent callback)
02Ticket issuance fails or is delayed
03Job persisted to Amazon SQS
04Retry / reconciliation worker
05Ticket issued once → status updated

— Problem

Booking and availability had to hold up under many simultaneous purchases during one live event, with the frontend never able to control ticket status directly.

— What I built

For the 15,000-ticket event I built the booking and availability logic server-side, plus a cron job that caught one nasty failure mode: payment succeeds, but a network blip stops the ticket from generating. It found paid orders with a pending ticket and retried them, flipping the status once sent so nothing duplicated, with an admin override for the rare leftovers. In 2026 I re-platformed it on AWS as containerised services: a Booking Service (reservations and booking state), a Payment Integration Service (provider requests, verified callbacks and webhooks, idempotent payment-state updates) and a Ticket Issuance Service (ticket and QR generation after payment confirmation, with duplicate-issuance protection). A separate retry/reconciliation worker now takes failed or delayed work from Amazon SQS, so recovery never blocks booking requests.

— My role

I built this solo, end to end: frontend, backend, database, booking flow, payment integration, ticket generation and deployment. I monitored and supported it in real time during the event, and later carried out the 2026 re-platform onto AWS and Kubernetes.

— Architecture

AWS (ap-south-1, Mumbai). Amazon EKS runs the production services, Amazon RDS holds relational data, Amazon SQS carries durable asynchronous work and Amazon S3 stores generated ticket artefacts where needed. The booking API, payment integration, ticket issuance and retry workers deploy and scale independently, with health probes, resource requests and limits, and controlled rollout and rollback. Worker capacity can change without touching the public booking service.

— The hard part

Keeping the booking → payment confirmation → ticket issuance lifecycle correct when callbacks arrive late or more than once, or when ticket generation fails after payment has succeeded. Idempotent state transitions, persisted job status and retry/reconciliation handling let repeated requests resume safely, with no duplicate tickets and no lost confirmed bookings.

— Under real load

After the migration the deployment was exercised on a live event: booking traffic, payment callbacks and ticket issuance. It validated the asynchronous recovery path and showed worker capacity scaling independently as the queue changed. Load tests also covered duplicate callbacks, delayed ticket generation and recovery after a worker failure.

→ Result

Handled 15,000+ sales across the event. The retry system recovered ticket-generation failures after successful payments automatically, so temporary network issues didn’t mean generating every affected ticket by hand.

React
Node.js
Express.js
Docker
Kubernetes
Amazon EKS
Amazon RDS
Amazon SQS
Amazon S3
Microservices
Payment gateway

02Actively maintainedP-02

AI Media Orchestration Platform

One interface over six generation models, built for the internal video and design teams.

~50%: faster per-asset turnaround
1,000+: assets generated
50+: client projects

Models: Kling · Veo 3 · Nano Banana 2 · ElevenLabs · Google Lyria · Google Imagen

01Prompt + model
02FIFO queue (rate-limit aware)
03Provider API
04Poll + auto-retry
05Saved to project directory

— Problem

Per-tool logins and paid seat limits slowed delivery and inflated cost. The team queued for shared AI accounts, and the agency licensed every tool whether or not a project needed it.

— What I built

I built a local web dashboard for image, video, SVG and audio generation that calls each provider’s API directly. A FIFO queue keeps requests under provider rate limits, with polling-based failure detection and automatic retries. Every project gets its own directory, so assets stay organised without manual filing.

— My role

I was the sole builder: architecture, implementation and ongoing maintenance. I chose the technical approach through my own testing and UAT.

→ Result

Roughly halved per-asset turnaround and lowered generation cost against the prior tooling.

Next.js
Node.js
Express.js
Python
REST APIs

03Revamped 2026 · in productionP-03

Rolls Mania Ordering & Inventory

Goldenoak and Unicorn: two regional platforms for 100+ stores across India. A full 2026 revamp of inherited code, now containerised and running on Kubernetes (AWS).

70+: Goldenoak stores
30+: Unicorn stores
100+: total stores

Bill No., PO No., contact and amount are blurred for confidentiality.

01Outlet
02Goldenoak / Unicorn (one image, two deployments)
03Order Management Service
04Inventory & Procurement Service (PO generation)
05LimeTray / POS Integration Service
06LimeTray

— Problem

I inherited both systems in 2026. The old code had inefficient database updates and a bug in how unique identifiers were used, so placing an order could add the wrong item and corrupt inventory at the outlet level.

— What I built

I read and mapped the existing codebases before touching anything, then rebuilt the data and identifier logic, the LimeTray integration and the frontend for both. In the same revamp I containerised the application and moved it onto Amazon EKS. Goldenoak and Unicorn are the same software, split by region so each area has its own point of contact, and they now run from one shared versioned image.

— My role

I inherited both codebases and revamped the backend, LimeTray integration and frontend for each, then containerised them and moved them onto Kubernetes on AWS. I maintain both in production, including live debugging.

— Architecture

AWS (ap-south-1, Mumbai), with Amazon EKS running the production workloads. The two systems share the same versioned image but deploy as two separate deployments with independent configuration, secrets, access controls and data boundaries, so their live data and operational config are never combined. Databases run separately from the application containers, so releases don’t couple database lifecycle to container lifecycle. Resource requests and limits, readiness and liveness probes, and controlled rollout and rollback settings keep deployments predictable.

— Services

Order Management owns the order lifecycle and status. Inventory & Procurement handles stock movements, inventory records and purchase orders, including PO generation. LimeTray / POS Integration isolates third-party API communication and sync from the core order and inventory workflows. They talk through explicit APIs and asynchronous events, with clear data ownership instead of unrestricted shared-table access.

— The hard part

Preserving existing order and inventory identifiers and validating records while migrating two region-specific deployments that had configuration differences. Before cutover I ran record-count and key-business-total checks, then did a staged rollout with a tested rollback path, which caught identifier mismatches and configuration issues before they reached store workflows.

→ Result

That class of ordering error is gone. Both platforms now share a versioned image and common service implementation, reducing code drift and duplicated maintenance. Releases are repeatable container deployments instead of system-specific manual setup, and POS integration failures no longer take down core order and inventory workflows.

PHP
MySQL
Docker
Kubernetes
Amazon EKS
AWS
Microservices
REST APIs
Cron jobs
Role-based auth

04In daily useP-04

BOPS · Employee Management CRM

Attendance, payroll, leave and project allocation in one system, replacing spreadsheet-based HR.

All: employees on one role-based system

Names, avatars and individual figures are blurred to protect privacy.

— Problem

Attendance, leave, employee data and project allocation lived in separate spreadsheets and manual processes, leaving management without a unified view.

— What I built

I built a centralised system with role-based access. Admins see everything, HR manages people operations, team leads manage their teams and allocation, and employees handle their own info, leave and daily tasks. It also covers punch-in/out, payroll, performance reviews, leads and reminders.

— My role

I built this solo: frontend, backend, APIs, database, authentication, role-based access and deployment.

→ Result

Attendance, leave and allocation now live in one place, cutting the manual work of keeping them current.

HTML
CSS
JavaScript
Node.js
Express.js
REST APIs

05Delivered · maintainedP-05

Seven More Client CRMs

E-commerce inventory and billing, lead generation and customer records for seven clients, all built solo.

20+: client websites

Clients: Reel Factory · Sunanda Mangal Kendra · Helios · Realtors India · Jaywant Group · MB Ashtekar Jewellers · Pera CET

— Problem

Most clients ran on spreadsheets and manual website updates.

— What I built

I built per-client, centralised management systems tailored to each business: product catalogue, billing, enquiries and customer records.

— My role

I built each one solo.

→ Result

Faster, cheaper-to-run operations with a single source of truth per client.

Node.js
PHP
MongoDB
MySQL
React

02 / Live sites

Live.

19 currently live · 20+ shipped across client projects. Pick any one and open it right here.

AnushkaUghade

Ship.

TicketAdda

— Problem

— What I built

— My role

— Architecture

— The hard part

— Under real load

→ Result

AI Media Orchestration Platform

— Problem

— What I built

— My role

→ Result

Rolls Mania Ordering & Inventory

— Problem

— What I built

— My role

— Architecture

— Services

— The hard part

→ Result

BOPS · Employee Management CRM

— Problem

— What I built

— My role

→ Result

Seven More Client CRMs

— Problem

— What I built

— My role

→ Result

Live.

Lexicon Networks

MB Ashtekar Jewellers

Pune Design School

GESP SSPU

Vyomic Facades

Realtors India

Max Grad

Jaywant Group

Luxelan

Kalacasa

Indian Women in Dubai

YSSPL

Peracet

Reel Factory

Geetikka Juneja

Devesh Siwal

Rolls Mania

Being Addictive

IST India

Operate.

Senior Full-Stack Developer

Web Developer

Education

Stack.

HireAnushka.

Anushka
Ughade