The interesting problems were never about the feature. They were about the system underneath it.
Most frontend problems eventually become communication problems.
The first time a production deployment broke something I didn't expect, I realized architecture decisions are really communication decisions — between you and the engineer who reads your code two years later.
Selected work
Nine systems built. Five documented here — from first frontend role to technical lead. Real constraints, honest tradeoffs, what they taught me. No screenshots, no client logos — engineering decisions speak louder than design covers.
A map of the things I think about, and the convictions that pull them together.
The connections between the things I think about. Not a hierarchy. A map of how one decision pulls on another.
Each one connects to the others. Each one has a thought behind it.
- 01
Performance is a feature.
- 02
State complexity should match business complexity — nothing more.
- 03
The best component is the one your team can delete safely.
- 04
Architecture decisions are really communication decisions.
Notes from production
Short reflections. Not polished. Real things I learned by building systems that other people had to live with.
When you inherit a system, the first instinct is to rewrite. The second instinct — earned painfully — is to understand.
Shipping features is easy. Keeping systems understandable after two years is the harder part of the work.
Performance optimization taught me restraint more than speed. Most of what I removed mattered more than most of what I added.
Working across three timezones taught me to write code the way I'd write a letter — assuming the reader won't be in the room to ask questions.
The best architecture decisions look obvious in retrospect. The bad ones do too.
Some systems failed quietly before they failed visibly.
Every visible change is the tail of an invisible flow.
- Eventuser action
- Asyncnetwork · queue
- Stateinvariants
- Deriveselectors
- Viewrender layer
Every visible change is the tail of an invisible flow.
Things I changed my mind about
The work changes you. These are some of the ways it changed me.
I used to build shared utilities the moment I saw a second use case. Clean interface — good abstraction.
The abstraction that cost the most wasn't wrong. It was just used by enough engineers that removing it took months. Replaceability matters more than reusability. I design for deletion now.
I thought state management was a frontend problem — something you solved by choosing the right store.
The worst state bugs I've debugged had nothing to do with the store. They were synchronization gaps between what the server knew and what the client assumed. The state model you pick is a statement about where you trust the server — and most of the time, that conversation hasn't happened yet.
I used to measure performance by what I could control: bundle size, render count, query time.
The system that held under 3,000 concurrent users held because concurrency shaped the architecture from the start. Performance constraints that arrive late don't just slow you down — they constrain what you're allowed to redesign.
What’s open in my mind right now.
Some of this is active learning. Some of it is unresolved thinking I haven’t finished yet. Both belong here.
- React Server Components at scale
- Multi-tenant architecture without tenant-specific code paths
- AI-assisted engineering workflows beyond autocomplete
- Architectures that survive team turnover
- Where product thinking should influence architecture decisions — and where it shouldn't.
- How frontend systems stay maintainable as teams and business complexity grow in opposite directions.
Three countries. Real production systems, not freelance side projects.
Israel
4Long-running engagements. Consumer scale and university platforms — stewardship across years, not handoffs.
- Consumer Coupon Platform5.5M+ redemptions
- Provider Campaign PortalCRM · 156k+ consumers
- B2B Multi-tenant SystemAI-layered · in production
- University Learning Platform3,000 concurrent · exam system
California, USA
2Full Stack Developer on both. AI features layered on B2B SaaS and regulated e-commerce.
- AI Proposal IntelligenceB2B SaaS · PEO services
- Regulated E-commerceCannabis delivery · POS + admin
India
3First production roles. Enterprise systems serving internal teams across the supply chain.
- Enterprise ERPJewelry · 600,000+ SKUs
- Distributor CatalogueStructured product data
- Employee ManagementHR + order coordination
Async-first · Cross-timezone · International delivery standards
The tools, grouped by what they actually do.
- React
- Next.js
- TypeScript
- JavaScript
- HTML
- CSS
- Tailwind
- Redux
- Node.js
- Express
- MongoDB
- PostgreSQL
- Supabase
- Claude Code
- Cursor
- OpenAI API
- GitHub Copilot
- v0
- MCP
- Git
- GitHub
- Vercel
- Docker
- Postman
- Figma
- Framer Motion
- Vite
One company. Trainee to Senior Engineer. Nine production systems. Three countries.
Most engineers change companies for variety. I changed domains — LMS, consumer, enterprise, AI. The scope kept expanding. So did the depth.
Senior Software Engineer
CurrentLeading full-stack engineering across Israel, California, and India. The decisions made here — what gets abstracted, where contracts live, how state flows — are the ones other engineers on the system build on.
Software Engineer
Designed the pre-production environment that bridged a silent staging/production divergence — zero impact on 156k live consumers and 5.5M+ redemptions. Built and shipped production systems across LMS, ERP, AI SaaS, and consumer platforms. Became the engineer called when a deployment decision affected everyone.
Trainee
Three months of hands-on React training with senior developers. Foundations before moving to live production work.
A few notes on how the work happens.
Good engineering survives sleep. Documentation, commit history, and clear decisions scale better than meetings.
I start at the user boundary and work backward. Frontend decisions become API decisions, API decisions become system decisions.
I reach for an abstraction the third time, not the first. Premature systems are how production becomes painful in eighteen months — for everyone who has to maintain them.
Let’s build something
that lasts.
Open to Senior Frontend, Frontend Systems, and Full Stack Engineering roles with teams shipping production across timezones. The systems that have to keep working two years from now.
Ahmedabad, India
Senior Software Engineer · React · Next.js · TypeScript · Production Systems · AI Products