Advertising से Engineering तक: DIALØGUE बनाने से Technical Lessons
मैंने AWS से GCP migrate किया और 10x faster performance के साथ 92% cost reduction हासिल किया — यहाँ है जो मैंने "best practices" छोड़कर pragmatic architecture अपनाने से सीखा जो actually काम करती है।
*यह मेरे DIALØGUE के introduction के technical deep-dive companion है। अगर आपने DIALØGUE क्या है और मैंने इसे क्यों बनाया यह नहीं पढ़ा, तो वहाँ से शुरू करें!*
Journey: Advertising Professional से Full-Stack Engineer तक
चलिए कमरे में मौजूद elephant को address करते हैं — हाँ, मैं advertising से आता हूँ। हाँ, media plans और creative briefs, data structures और algorithms नहीं। लेकिन funny बात यह है: systems कैसे काम करते हैं यह समझना — चाहे marketing funnel हो या distributed architecture — उसी analytical mindset की ज़रूरत है। फर्क? Engineering में, जब आप गड़बड़ी करते हैं, तो computer आपको तुरंत बता देता है। campaign results का इंतज़ार नहीं करना पड़ता haha।
DIALØGUE बनाना... intense रहा है। यह सिर्फ code लिखना नहीं है (हालाँकि वह भी बहुत हुआ है)। यह एक complex system architect करना है जिसे somehow multiple AI services orchestrate करने, asynchronous workflows handle करने, और users के unexpected काम करने पर टूटना नहीं है। मैं share करना चाहता हूँ कि यह journey मुझे actually क्या सिखाई — अच्छा, frustrating, और "मुझे यह पहले क्यों नहीं बताया" के पल।
Architecture Decisions: Complexity दुश्मन क्यों है
यहाँ एक बात है जो शुरुआत में कोई नहीं बताता: complexity आपका दोस्त नहीं है। मैंने यह the hard way सीखा। सच में बहुत मुश्किल तरीके से। मुझे CloudWatch logs में डूबते हुए picture करें, यह समझने की कोशिश करते हुए कि मेरी beautifully architected system क्यों... काम नहीं कर रही थी। T.T
Initial Architecture (ज़रूरत से ज़्यादा Complex)
तो मैंने orchestration के लिए LangGraph से शुरुआत की। क्यों? क्योंकि graph-based approach इतना elegant लग रही थी! यह flexibility देती! यह beautifully scale होती!
Reality check: यह painfully slow था। Locally run करने पर भी। उनके cloud deployment पर भी। वह सारा beautiful abstraction बस... overhead था। बहुत सारा overhead।
Final Architecture (Pragmatically Simple)
काफी soul-searching (और debugging) के बाद, यह actually काम करता है:
```
Frontend (Next.js) → API Gateway → Cloud Run Services → Cloud Workflows → Cloud Storage
↓
Supabase (Auth + Real-time + PostgreSQL + Edge Functions)
```
Note: हमने July 2025 में AWS Lambda/Step Functions से GCP Cloud Run/Workflows में migrate किया, जिससे 92% cost reduction और 10x performance improvement हुआ।
बड़ा Revelation: जब मैंने APIs में सब कुछ wrap करने के बजाय direct Supabase queries पर switch किया, तो 10x performance improvement मिला (450ms → 45ms)। वह सारा "proper" API layering? यह सब slow कर रहा था। यह database-first architecture हमारे GCP migration की नींव बनी।
AI Model Selection: Hype के परे
Model Landscape की Reality
चलिए AI models की बात करते हैं। मैंने इन सब को try किया है। सच में — सिर्फ एक दोपहर के लिए नहीं। महीनों की testing (और मैं admit करने से ज़्यादा API credits जलाने) के बाद, यह actually काम करता है जब आप कुछ real build करते हैं:
मेरा Current Go-To Stack:
- Claude (via Claude code) & Gemini 2.5 Pro (via Gemini CLI): मेरी core development duo। ये दोनों models इतने capable हो गए हैं कि इन्होंने essentially मेरे workflow में बाकी सब कुछ replace कर दिया है।
- Claude Sonnet 4 API: JSON reliability के लिए temperature 0 के साथ DIALØGUE की script generation को power देता है
मेरा Stack पहले क्या Include करता था:
DeepSeek: मैं tricky bugs debug करने के लिए इस पर rely करता था, खासकर late-night troubleshooting sessions में। लेकिन एक बार Claude 4 और Gemini 2.5 Pro आए? वे उन edge cases को उतनी ही अच्छी तरह, या बेहतर भी, handle करते हैं। Model capability का evolution ने मेरे workflow के लिए specialized debugging models को redundant बना दिया।
Actually क्या काम करता है:
यहाँ interesting बात है: हर model अपने आप में already incredibly powerful है। Claude architectural thinking और complex reasoning में brilliant है। Gemini 2.5 Pro? Implementation और massive codebases में context maintain करने में absolutely phenomenal। Gemini 2.0 से 2.5 की jump insane थी — मैं literally feel कर सकता था difference। तेज़ responses, 1M token context window (हाँ, सच में), और यह actually समझता है कि मैं क्या build करने की कोशिश कर रहा हूँ।
लेकिन यहाँ असली magic होती है: जब आप उन्हें एक-दूसरे के काम को critique करवाते हैं। मैं Claude से एक approach design कराऊँगा, फिर Gemini से review करवाऊँगा और improvements suggest कराऊँगा। या Gemini एक solution generate करेगा, और मैं Claude से edge cases या architectural concerns के लिए analyze कराऊँगा। वह back-and-forth, वह collaborative critique process — वहाँ आपको breakthrough solutions मिलती हैं जो अकेले कोई भी नहीं पहुँचता।
जो काम नहीं किया (Hype के बावजूद):
- OpenAI o1/o3: सब इनके बारे में बात कर रहे हैं, लेकिन actual development के लिए? बहुत slow, बहुत expensive, और honestly मेरे use cases के लिए उतना better नहीं।
- GitHub Copilot Workspace: Great idea, लेकिन वे token limits... जब भी मैं कुछ substantial करने की कोशिश करता तो ceiling से टकरा जाता
Real Insight: जानते हो क्या कोई नहीं बताता? Different models differently fail करते हैं। Early Gemini कुछ errors पर weird loops में फँस जाता था — बस problem नहीं देख पाता था। Claude इसे immediately spot कर लेता। लेकिन तब Claude simple implementations को overthink करता जो Gemini seconds में nail कर लेता। Trick "best" model ढूंढना नहीं है — यह जानना है कब switch करना है।
Full-Stack Development: Multiple Hats पहनना
Terminal Strategy
यहाँ एक practical बात है जिसने actually मेरी sanity बचाई: अलग-अलग contexts के लिए separate terminal windows। Simple लगता है? यह game-changing है।
```bash
# Terminal 1: Frontend Developer मैं
cd podcast_generator_frontend_v2
npm run dev
# यहाँ मैं React components और user experience के बारे में सोचता हूँ
# Terminal 2: Backend Developer मैं
cd gcp_services
./deploy/deploy-service.sh [service-name]
# यहाँ Cloud Run services रहती हैं (Lambda से बहुत खुश!)
# Terminal 3: Database मैं
supabase start --workdir supabase
# Local Supabase testing के लिए, production real work के लिए
```
मुझे पता है यह ridiculous लगता है, लेकिन terminals के बीच physically switch करना मेरे brain को contexts switch करने में मदद करता है। Frontend मैं और backend मैं अलग लोग हैं, और उन्हें अपनी spaces चाहिए।
Cross-Stack Communication
Full-stack पर solo काम करना weird है। आप essentially खुद से conversations कर रहे हैं। इसलिए मैंने notes छोड़ना शुरू किया:
```
// Note from Frontend Me to Backend Me
/**
* BACKEND TODO:
* - Need endpoint GET /api/podcasts/:id/segments
* - Should return: { segments: Array<{id, title, status, content}> }
* - Must handle: 404 (not found), 403 (unauthorized)
* - Real-time updates via Supabase subscription would be ideal
* - Future me will thank you for error handling!
*/
```
```
## Backend Developer Summary for Frontend Integration
Current State:
- Endpoints implemented: POST /podcasts, GET /podcasts/:id
- Authentication: Bearer token via Supabase JWT
- Real-time: Supabase channel "podcast-updates"
Next Frontend Tasks:
1. Implement podcast creation form
2. Subscribe to real-time updates
3. Handle error states (401, 403, 404, 500)
```
ये छोटे notes? जब मैं एक हफ्ते बाद code पर वापस आता हूँ और past-me क्या सोच रहा था यह नहीं जानता — absolute lifesavers।
Key Technical Takeaways
1. Systems Thinking Domains से परे है
मेरे advertising background ने मुझे systems में सोचना सिखाया — user journeys, conversion funnels, attribution models। ये mental models directly translate होते हैं:
- Distributed system design में
- User experience flows में
- Performance optimization में
- Error handling strategies में
2. Production-First Mindset
# क्या prioritize करना सीखा मैंने
if works_in_production and meets_user_needs:
ship_it()
else:
fix_only_blockers()
# Perfect done का दुश्मन है
3. Full-Stack Competency Real है
DIALØGUE बनाने के लिए ज़रूरी था:
- Frontend: React 19, Next.js 15, TypeScript, real-time subscriptions, WebSocket management (memory leaks fix!)
- Backend: Python 3.12, Cloud Run (14 microservices), Cloud Workflows, PostgreSQL (Supabase के ज़रिए)
- Infrastructure: GCP (AWS से migrate), API Gateway, Cloud Storage, frontend के लिए Vercel
- AI/ML: Claude 4.0, Perplexity API, OpenAI TTS, temperature optimization (JSON के लिए 0)
- DevOps: Docker containers, Cloud Build, monitoring, JWT security (P-256 migration)
- Database: RLS के साथ PostgreSQL, Edge Functions, race condition prevention के लिए atomic operations
4. Classical Training का महत्व
Formal software engineering training (system design, data structures, algorithms) अमूल्य साबित हुई। यह सिर्फ AI से code लिखवाने के बारे में नहीं है — यह जानने के बारे में है कि क्या माँगना है और इसे कैसे architect करना है।
Final Thoughts
तो यहाँ है जहाँ मैं इन सब के बाद पहुँचा हूँ: DIALØGUE बनाने ने पूरी तरह से बदल दिया कि मैं खुद को professionally कैसे देखता हूँ। मैं वह आदमी हुआ करता था जो technical teams manage करता था। अब? मैं actually उनके साथ build कर सकता हूँ। और honestly, यह बहुत amazing feel होता है। :D वह evolution तब जारी रही जब मैंने Swift जाने बिना एक native iOS app बनाना शुरू किया — पता चला कि advertising skills (taste, creative direction, यह feel करना कि "good" कैसा लगता है) coding skills से ज़्यादा matter करती हैं।
Advertising से engineering तक की journey सिर्फ syntax या frameworks सीखने के बारे में नहीं है। यह अपने brain को systems में सोचने, methodically debug करने, और यह accept करने के लिए rewire करने के बारे में है कि कभी-कभी आप एक missing semicolon पर 3 घंटे बिताएंगे (okay, TypeScript वह पकड़ता है, लेकिन आप समझ गए)।
Funny बात जानते हो? Advertising से analytical thinking — user journeys समझना, conversion funnels optimize करना, वह सब stuff — directly engineering में translate होती है। फर्क यह है कि code में, जब कुछ काम नहीं करता, तो computer तुरंत बता देता है। Campaign reports का इंतज़ार नहीं। बस immediate, brutal feedback।
"Product" podcast.chandlernguyen.com पर live है। यह काम करता है। Perfect नहीं है, लेकिन मेरा है। और हर bug fix, हर feature addition, हर "aha!" moment — ये सब इस ongoing journey का हिस्सा हैं।
क्या आपने कभी ऐसा career pivot किया है — एक domain से किसी बिल्कुल different चीज़ में? मुझे जानना अच्छा लगेगा कि transition में आपको सबसे ज़्यादा क्या surprising लगा। बताइए!
शुभकामनाओं सहित,
Chandler
P.S: सीखने की hard way की बात करें तो — जानना चाहते हैं कि एक tiny AI parameter change ने मुझे $54/month कैसे cost किया? One AI Parameter Change Cost Me $54/Month देखें। यह एक cautionary tale है कि क्या होता है जब आप AI assistants पर production constraints के बारे में explicit हुए बिना production code trust करते हैं। Spoiler: "make it work" और "make it production-ready" बहुत अलग requests हैं।
P.P.S: मैं अभी भी इस पूरे engineering thing को figure out कर रहा हूँ, एक bug at a time। Currently AI-powered applications build करते हुए production नहीं तोड़ने की कोशिश कर रहा हूँ। बाद में इस blog पर और के लिए वापस आएं।
