Skip to main content

Command Palette

Search for a command to run...

What coding tutorials don't teach you about pushing to Prod

Updated
3 min read
What coding tutorials don't teach you about pushing to Prod

I recently wrapped up the architecture for my first major B2B client project. I want to share some honest, behind-the-scenes thoughts—not just the wins, but the exact code and business logic it took to get there.

Because building a local side project is easy. But when your code handles a live business's cash flow, the stakes change entirely.

Here are the highest highs, the lowest lows, and how I actually fixed them.

The Lows (The "Why is this broken?" moments)

The iOS Security Wall (ITP Protocol) My frontend was deployed on Vercel and the backend on Render. Standard MERN setup, right? But suddenly, iPhones started blocking our authentication.

  • The Problem: Apple’s strict ITP (Intelligent Tracking Prevention) protocol fiercely blocks cross-site cookies and requests. Because Vercel and Render use different root domains, iOS treated our API calls as third-party tracking and killed them.

  • The Fix: I had to instantly buy the production domain early and map custom subdomains (like app.domain.com and api.domain.com) so the browser recognized them as a secure, first-party context.

The Midnight Paradox Computers are painfully literal. To a server, 1:00 AM on Monday is Monday morning. But to a business owner in India, a shift running until 1:00 AM on Monday is actually their Sunday night shift.

  • The Fix: I had to completely hijack the chronological sorting. Before sorting the arrays for the admin dashboard, I offset the server time by the shift hours so the UI matched actual human psychology.

The Syntax:

// Shift boundary logic: Offset time by 6 hours to group late-night bookings into the previous business day.
const actualDate = new Date(bookingTime);
const businessDate = new Date(actualDate.getTime() - (6 * 60 * 60 * 1000));

// Now run the sorting logic using businessDate instead of actualDate

Highs (The "This actually works" moments)

  1. The Multi-Tenant Pivot The client initially asked for a simple custom app. But instead of hardcoding a one-off tool, I abstracted the entire architecture into a white-labeled SaaS core. We built one highly scalable engine that can be rebranded for infinite clients in the future.

  2. Bypassing the 2% Gateway Tax Standard payment gateways take a 2% cut on every transaction. Small businesses bleed revenue this way. I engineered a custom Direct-UPI architecture that bypasses the gateway entirely, meaning the client keeps 100% of their money with zero commission fees.

The Biggest Lesson - Writing Code for Business Growth

Writing the logic for the discount and promo-code engine was honestly terrifying. If your alphanumeric validation or bulk-hour math is off by a single decimal, the client loses real money instantly.

But it was also the biggest win. I engineered the Promo Engine to give the admin three completely independent controls:

✅ Time-Bound: Promo codes valid only for specific days/hours.

✅ Usage-Bound: Codes that expire after the first 50 people use them. ✅ User-Bound: Codes restricted exclusively to first-time users.

The Result: By automating this, manual management efforts dropped to near zero. The owner stopped fighting WhatsApp chaos and finally had the time to focus on scaling the actual business.

Writing code is just the baseline. Architecting a system that perfectly bridges complex edge cases with real-world business logic—that is where the real engineering happens.

If you are an engineering manager, recruiter, or founder building scalable backend systems, let's connect. I'm actively looking for my next big challenge! 🚀

#SoftwareEngineering #BackendDeveloper #SystemDesign #ReactJS #NodeJS #WebDevelopment #SaaS #TechJourney #EngineeringLeadership