Famcare - Founding Engineer & Tech Lead
Duration: April 2026 - Present
Role: Founding Engineer & Tech Lead
Website: famcare.co.in
Overview
Architected and delivered the FamCARE full-stack ecosystem — a FastAPI backend, a Flutter customer app, a Capacitor-based caretaker app, and a Next.js admin dashboard — scaling from zero to production across 4 repositories. Personally authored 679 commits (~105,000 lines added) as the top contributor on every repo, while mentoring a team of 7 engineering interns who collectively shipped 554 commits and 113,000+ lines of code under direct technical guidance.
Key Accomplishments
- Architected and delivered the FamCARE full-stack ecosystem — a FastAPI backend, a Flutter customer app, a Capacitor-based caretaker app, and a Next.js admin dashboard — scaling from zero to production across 4 repositories. Personally authored 679 commits (~105,000 lines added) as the top contributor on every repo.
- Led system design and core technical architecture as the founding engineer, setting the technical direction for the platform from inception.
- Mentored and led a team of 7 engineering interns, hand-holding them through codebase ramp-up, code reviews, and best practices — the team collectively shipped 554 commits and 113,000+ lines of code across the same 4 repos under direct technical guidance.
- Engineered a high-throughput API architecture, verified via custom stress testing to handle 2,000+ requests/minute and 100 concurrent users with a 100% success rate for core operational flows.
- Engineered a modular monolith architecture with 25+ decoupled services designed for the Strangler Pattern, managing complex Order/Booking flows, Razorpay payments, and a multi-channel notification engine (FCM, Fast2SMS, MSG91).
- Optimized operational velocity, reducing deployment cycles by 70% through Fastlane CI/CD (confirmed in both the Flutter and Capacitor apps) and automating caregiver background checks via SpringVerify, while maintaining sub-second WebSocket-based real-time tracking.
📈 Quantified Impact Metrics (Cute & Mighty!)
⚡ Engineering Strength Metrics ⚡
🌟 Dynamic Repo Explorers (Tap to Expand!)
We didn't just build an app—we spawned an entire digital universe! Expand each tab below to view our repository blueprints:
The core engine. Handles distributed transactional states, real-time sync, and idempotent migration nodes.
- Modular Architecture: Decoupled router-service-repository patterns built on FastAPI.
- Dispatch Engine: Automated sequential booking queues and async scheduler states.
- Unified Wallet System: Ledger transactional accounting with Razorpay checkout verification.
- FCM notification: Broadcast pipelines delivering targeted user and rider notifications.
- WebSocket migration: Decoupled messaging by migrating local memory sync to a robust DB-backed socket stream.
The consumer-facing portal. Handles multi-pet onboarding, visual live map tracking, and secure transactions.
- Smart Questionnaire: Tailored forms dynamically building Child, Elderly, and Pet Care flows.
- Real-time Tracking: Live proximity mapping with Geolocator and sub-second WebSockets.
- Dynamic Pricing preview: Real-time coupon application and multi-pet pricing logic.
- Fastlane Mobile CI: Direct automatic releases, localization updates, and Play Store pipeline deploys.
Empowering local caregivers with task bidding, live chat, active availability states, and AWS S3 security proof checks.
- Task Bidding: Custom provider dashboards with live booking proposals and real-time alerts.
- In-app Chat: Direct customer-caregiver messaging built on the same real-time backplane as live tracking.
- Foreground Timer Patch: Solved Android chronometer tick bugs by resetting foreground notifications upon task status state changes.
- Secure Check-ins: Direct AWS S3 photo capturing flow for secure check-in/out proofs.
- Fastlane CI/CD: Automated build, signing, and store deployment alongside the customer app.
The high-powered operations console giving the internal team absolute control over orders, riders, and finances.
- Financial Reporting: Real P&L in daily report PDFs, cancellation tracking, MTD/YTD analytics with custom date-range filters.
- Rider Dashboards: Salary and revenue-utilization dashboards plus a full audit log of admin actions.
- Slot Allocation: Advanced scheduling slots, capacities, and operational hour overrides.
- Dynamic BGV Approval: SpringVerify status review panel with manual override flags, handling provider 404s gracefully.
- Feature Flags: Per-feature off / dev_only / live gating to ship new code paths without exposing them before they're ready.
- Cohort Broadcasts: FCM notification center filtering targeted user/caretaker segments, plus manual OTP regeneration and referral backfills.
Infrastructure Modernization
Brought the entire production stack under infrastructure-as-code, stood up a fully isolated staging environment, and wired up CI/CD — all with zero production downtime.
Terraform from scratch, modeled on live infrastructure
Built a reusable Terraform module library (VPC, ALB, ECS cluster, ECS service, RDS, IAM) by running a full read-only audit of the existing AWS account, then writing modules generic enough to describe both the existing production stack and a new staging stack from the same code, with only input values differing between environments.
Zero-downtime import of live production into Terraform state
Imported every existing production resource — VPC, subnets, 3 security groups, ALB with listeners and target groups, ECS cluster and all 3 running services (API, background agent, scheduler) with their task definitions, the Aurora RDS cluster, and IAM roles — directly into Terraform state via terraform import. Nothing was created, modified, or destroyed.
Iteratively reconciled every mismatch until terraform plan showed zero forced replacements and zero destroys — the gold-standard signal that the codebase now describes production with complete fidelity. Along the way, fixed several pre-existing gaps that would otherwise have caused an unintended outage:
- A missing
descriptionfield on security groups (AWS treats it as immutable — would have force-replaced live, in-use groups) - An incorrect assumption about RDS master password management mode
- Task definition revision drift from a mid-project redeployment
- Missing container-level config (health checks, per-container CPU, log configuration) silently defaulted by the AWS API
Net-new, isolated staging environment
Designed and built staging as a genuinely separate ECS cluster — its own private Aurora Serverless v2 database, its own security groups, its own IAM roles — sharing only the production VPC and load balancer for cost efficiency, via new path-based ALB routing rules (/api/* → production, /staging/api/* → staging) added additively without touching any existing routing behavior.
During first live deployment, diagnosed and fixed four non-obvious bugs in sequence: IAM role missing Secrets Manager read, missing logs:CreateLogGroup grant (the AWS-managed ECS policy only grants log stream creation, not group creation), a URL-encoding bug in the database connection string breaking on special characters in the generated password, and a driver-scheme mismatch between the app's runtime and its migration tooling (postgresql:// vs postgresql+asyncpg://).
Application change for path-based multi-tenancy
AWS ALB has no path-rewrite capability — it forwards the full incoming path unchanged. Shipped a small, backward-compatible change to the FastAPI backend making the API's URL prefix configurable via environment variable, defaulting to existing /api behavior so production was unaffected. This lets one codebase serve both /api/* (prod) and /staging/api/* (staging) correctly.
CI/CD pipeline for staging
Wrote a new GitHub Actions workflow mirroring the production deploy pipeline (build → push to ECR → run migrations → update ECS service → wait for stability), fully re-scoped to the staging cluster and triggered on pushes to the staging branch. Verified end-to-end on a live run: image build, 110+ sequential Alembic migrations on a freshly-provisioned database, service deployment, and health-check convergence — while confirming production remained completely unaffected throughout.
Security hardening
Surfaced and remediated two live security issues discovered during the audit: plaintext credentials (Slack tokens, an OAuth client secret) sitting in non-secret container environment variables instead of Secrets Manager; and a pre-existing, publicly-accessible database (open security group, no VPC isolation) flagged for decommissioning — the new staging database was built private-only from the start specifically to not repeat that mistake.
App Store & Play Store Downloads
Product Screenshots
