I don't just write code.
I decide what to build and why.
Architecture, security, payments, admin systems, ads. I own the whole product, not just a slice. Below is how I actually think, organised by the type of problem, not the technology used.
Engineering & Architecture
Systems built from scratch. Full ownership from database to deployment.
Freelance · Live · Solo build
Ridiviaanh - a booking platform that runs without me
Trek bookings, meal planning, dynamic slot availability, group pricing, Razorpay payments, partner inquiry, notify-me system. The real engineering challenge wasn't the booking flow — it was designing a zero-touch admin panel so the client never calls me after launch. I built the admin first. The customer layer came after.
10-minute slot holds prevent double-bookings during payment. Two people trying to book the same slot at the same time — that's a concurrency problem. The hold is visible to the user, not just stored in the database. Security designed in from day one: honeypot → reCAPTCHA v3 → rate limiting → input validation. Each layer with a reason, not a checklist. 10–12 days of architecture planning before a single line of code.
↳ 13 confirmed bookings · Zero developer dependency · Expanding with partner portal + hotels
Production · COMCON · Performance
Teaching a system to ignore panic
See it — without vs with the 300ms filter
300ms — the human perception window. Fast enough to feel instant. Long enough to absorb natural scroll bursts.
Why 300ms — not 500, not 100
"Who decides which event is the right one?"
At 500ms, users feel the lag. At 100ms, fast scroll bursts still slip through. 300ms is the sweet spot. Events from a natural scroll arrive within 300ms of each other. Silence after that means the gesture is done. Not a technical number — a human one. Result: 80% of excessive events eliminated. Scroll stays smooth.
↳ 10% speed boost · 15% overall performance improvement · Measured in production
Production · COMCON · Performance
Faster, leaner, searchable — without breaking what's live
The constraint was real: don't change the structure, don't break what's deployed. Migrated to Cloudflare for edge caching. Reduced third-party dependency and improved load time without a rebuild. Cleaned the codebase, fixed backend form handling, and updated all content for SEO. Added structured metadata for search and AI crawler readability. Validated with Lighthouse. The discipline here wasn't building — it was improving without the luxury of starting over.
↳ Faster load · Reduced third-party calls · SEO-ready and AI-indexed
Growth & Business Systems
Where engineering meets revenue. Ads, SEO, analytics, B2B strategy.
Ongoing · COMCON & Freelance
The layer most engineers hand off
Running performance marketing alongside product development. Meta Ads, Instagram Ads, Google Ads, SEO, analytics, conversion tracking, domain operations. I handle the full loop: build the product, understand the user, run the campaign, measure what breaks.
Most engineers can't explain what they built to a non-technical person. Most marketers can't understand why the system works the way it does. I sit between both. That's where the interesting problems are.
Implemented full technical SEO across three live websites: Search Console setup, GA4 analytics, Lighthouse performance audits, sitemap indexing, and image optimisation.
↳ Full loop ownership: product → user → campaign → measurement
Production · COMCON · B2B
Why I didn't automate the B2B order workflow
High-value B2B orders don't work like checkout buttons. Third-party gateways charge a percentage per transaction with no ceiling — on large orders, that's a significant cut for nothing in return. Built a dynamic QR code and UPI ID system instead. No gateway fee. No third-party dependency.
Customer gets an automatic payment confirmation. Order confirmation is cross-verified by admin before anything moves. At this order value, a human in the loop isn't a weakness — every order involves negotiation, not just payment.
At current order volumes, manual verification adds value. Automation makes sense when volume outgrows the relationship. Right now it doesn't. Deliberate restraint is harder than adding features.
↳ Dynamic QR + UPI system built · Admin cross-verification in place · Zero gateway fees
Communication & Consulting
Smaller work. Bigger impact. Systems are useless if humans can't operate them.
National broadcaster · 60+ engineers · COMCON
Doordarshan — 40% fewer support queries, same software
Trained 60+ broadcast engineers over 2 days on installation, troubleshooting, and application workflow. Then redesigned documentation and training videos around how engineers actually think — not how the product works.
40% reduction in support queries. Not from better software. From clearer communication. That's a product insight I carry into every system I build now.
↳ 40% support query reduction · National broadcaster · Delivered solo
Consulting · EdTech architecture
Architecture guidance for a quiz-based education platform
Consulted on database structure for questions, users, attempts, results, and progress tracking. Admin panel design, student dashboard logic, scaling for high student volume, low-cost MVP setup. Practical guidance an intern team could execute without a senior architect on call.
↳ Technical clarity for non-technical decision-makers
How I think
The decisions behind the work. Architecture is judgment, not just execution.
Decision 01
Why I built the admin panel before the customer-facing features
If the client can't manage their own content, they're dependent on me forever. The admin panel is the real product. The customer layer is just what's visible. I design operational independence before I design the experience.
Decision 02
Why 10–12 days of planning before writing a line of code
First time owning a system end to end. I thought through failure modes, concurrency, load, and what would break at scale. Not because I expected 5 lakh users immediately — because I didn't want the architecture to collapse if they came. Thinking before building is the discipline most people skip.
Decision 03
On using AI as a partner, not a replacement
I use AI to go faster through what I already understand — debugging, finding patterns, exploring tradeoffs. The architectural decisions are mine. The question of what to build and why is always mine. AI helps me unlock parts I'd otherwise slow down on. That's the only honest way to describe it.