[{"data":1,"prerenderedAt":389},["ShallowReactive",2],{"youtube-videos-v7":3,"posts-v2":260},[4,15,24,34,43,52,60,68,76,83,92,101,108,115,124,130,137,144,151,158,165,172,179,188,195,202,209,216,223,230,237,244,253],{"id":5,"title":6,"description":7,"url":8,"thumbnail":9,"date":10,"dateLabel":11,"views":12,"viewsLabel":13,"category":14},"dpje3HwSH3s","My Life at 25: No Filters, No Edits","","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=dpje3HwSH3s","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002Fdpje3HwSH3s\u002Fhqdefault.jpg","2025-11-29T13:46:31+00:00","9 months ago",596,"596 views","life",{"id":16,"title":17,"description":7,"url":18,"thumbnail":19,"date":20,"dateLabel":21,"views":22,"viewsLabel":23,"category":14},"xNa8kAEIaQg","We are made of the same light. 🧿❤️🫂","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=xNa8kAEIaQg","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FxNa8kAEIaQg\u002Fhqdefault.jpg","2026-08-29T17:53:05+00:00","3 weeks ago",414,"414 views",{"id":25,"title":26,"description":7,"url":27,"thumbnail":28,"date":29,"dateLabel":30,"views":31,"viewsLabel":32,"category":33},"XWD_T0op2vA","Mumbai: Where Some Live Dreams & Some Just Survive","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=XWD_T0op2vA","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FXWD_T0op2vA\u002Fhqdefault.jpg","2026-03-21T11:37:51+00:00","6 months ago",81,"81 views","mumbai",{"id":35,"title":36,"description":7,"url":37,"thumbnail":38,"date":39,"dateLabel":30,"views":40,"viewsLabel":41,"category":42},"nfn5S4Y7oQA","ChessTV #06: Can I Reclaim My Chess Rating?","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=nfn5S4Y7oQA","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002Fnfn5S4Y7oQA\u002Fhqdefault.jpg","2026-03-09T13:14:06+00:00",111,"111 views","chess",{"id":44,"title":45,"description":7,"url":46,"thumbnail":47,"date":48,"dateLabel":49,"views":50,"viewsLabel":51,"category":14},"FU1buhuKZZQ","Throwback to endless giggles! 🫶🥹","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=FU1buhuKZZQ","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FFU1buhuKZZQ\u002Fhqdefault.jpg","2025-03-12T11:49:30+00:00","1 year ago",72,"72 views",{"id":53,"title":54,"description":7,"url":55,"thumbnail":56,"date":57,"dateLabel":49,"views":58,"viewsLabel":59,"category":14},"Mbd2e-eYJBs","Reel dedicated to my sister \u002F best friend. ❤️🥹 #sister #behan #happy #family","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=Mbd2e-eYJBs","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FMbd2e-eYJBs\u002Fhqdefault.jpg","2025-02-09T14:36:49+00:00",665,"665 views",{"id":61,"title":62,"description":7,"url":63,"thumbnail":64,"date":65,"dateLabel":49,"views":66,"viewsLabel":67,"category":14},"_4pxYBVN4N8","A Sky Full of Stars in Ahmedabad 🌌 | Coldplay Live Magic ✨🎶 #coldplay #ahmedabad","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=_4pxYBVN4N8","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002F_4pxYBVN4N8\u002Fhqdefault.jpg","2025-01-28T16:05:02+00:00",667,"667 views",{"id":69,"title":70,"description":7,"url":71,"thumbnail":72,"date":73,"dateLabel":49,"views":74,"viewsLabel":75,"category":14},"zZNj0-CQFQk","Paradise in Ahmedabad 🌏🎤 | Coldplay Concert Highlights 🎶 #coldplay","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=zZNj0-CQFQk","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FzZNj0-CQFQk\u002Fhqdefault.jpg","2025-01-28T15:44:50+00:00",801,"801 views",{"id":77,"title":62,"description":7,"url":78,"thumbnail":79,"date":80,"dateLabel":49,"views":81,"viewsLabel":82,"category":14},"OWgRAR373kA","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=OWgRAR373kA","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FOWgRAR373kA\u002Fhqdefault.jpg","2025-01-28T15:44:41+00:00",654,"654 views",{"id":84,"title":85,"description":7,"url":86,"thumbnail":87,"date":88,"dateLabel":89,"views":90,"viewsLabel":91,"category":42},"pMoZ6rTfsSc","ChessTV, Game 05: Restarting My Journey","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=pMoZ6rTfsSc","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FpMoZ6rTfsSc\u002Fhqdefault.jpg","2024-12-24T17:38:23+00:00","Streamed 1 year ago",5,"5 views",{"id":93,"title":94,"description":7,"url":95,"thumbnail":96,"date":97,"dateLabel":49,"views":98,"viewsLabel":99,"category":100},"yFj3vPW4_fo","LeetCode, 01: Two Sum","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=yFj3vPW4_fo","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FyFj3vPW4_fo\u002Fhqdefault.jpg","2025-09-22T07:26:04.264Z",62,"62 views","coding",{"id":102,"title":103,"description":7,"url":104,"thumbnail":105,"date":97,"dateLabel":89,"views":106,"viewsLabel":107,"category":42},"WQ9DCLKUaJk","ChessTV, Game 04: Playing Chess so people find me cool and intelligent","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=WQ9DCLKUaJk","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FWQ9DCLKUaJk\u002Fhqdefault.jpg",12,"12 views",{"id":109,"title":110,"description":7,"url":111,"thumbnail":112,"date":97,"dateLabel":49,"views":113,"viewsLabel":114,"category":33},"CxP-GcyTS4M","POV: You are in Bombai Nagariyan. 🏙️🫣","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=CxP-GcyTS4M","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FCxP-GcyTS4M\u002Fhqdefault.jpg",61,"61 views",{"id":116,"title":117,"description":7,"url":118,"thumbnail":119,"date":120,"dateLabel":121,"views":122,"viewsLabel":123,"category":14},"bg30SKkF8jk","if you ever feel like something is missing in your life, come to Udaipur. 💕🕊️🥹 #Udaipur #LakeCity","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=bg30SKkF8jk","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002Fbg30SKkF8jk\u002Fhqdefault.jpg","2024-09-22T07:26:04.264Z","2 years ago",91,"91 views",{"id":125,"title":126,"description":7,"url":127,"thumbnail":128,"date":120,"dateLabel":129,"views":90,"viewsLabel":91,"category":42},"o1Q06dtoteI","ChessTV, Game 03: How Not To play Chess","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=o1Q06dtoteI","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002Fo1Q06dtoteI\u002Fhqdefault.jpg","Streamed 2 years ago",{"id":131,"title":132,"description":7,"url":133,"thumbnail":134,"date":120,"dateLabel":121,"views":135,"viewsLabel":136,"category":14},"KtXXc8Jdbho","Grah Pravesh Invitation Video","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=KtXXc8Jdbho","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FKtXXc8Jdbho\u002Fhqdefault.jpg",136,"136 views",{"id":138,"title":139,"description":7,"url":140,"thumbnail":141,"date":120,"dateLabel":121,"views":142,"viewsLabel":143,"category":33},"AeykAteZvR0","Juhu Beach, Mumbai","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=AeykAteZvR0","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FAeykAteZvR0\u002Fhqdefault.jpg",32,"32 views",{"id":145,"title":146,"description":7,"url":147,"thumbnail":148,"date":120,"dateLabel":121,"views":149,"viewsLabel":150,"category":14},"KH2B1xgU9x0","Trek 02, Kareri Lake Trek: Trekking Paradise in Himachal","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=KH2B1xgU9x0","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FKH2B1xgU9x0\u002Fhqdefault.jpg",142,"142 views",{"id":152,"title":153,"description":7,"url":154,"thumbnail":155,"date":120,"dateLabel":121,"views":156,"viewsLabel":157,"category":33},"jV2LaDJj7yU","POV: You are in Mumbai. ❤️ #mumbai #reels #shorts #shortvideo #rain #mumbaidiaries","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=jV2LaDJj7yU","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FjV2LaDJj7yU\u002Fhqdefault.jpg",442,"442 views",{"id":159,"title":160,"description":7,"url":161,"thumbnail":162,"date":120,"dateLabel":121,"views":163,"viewsLabel":164,"category":33},"Q7ebDJYp-1k","Trek to Garbett Point #trekking #trek #mumbai #weekend #selfcare","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=Q7ebDJYp-1k","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FQ7ebDJYp-1k\u002Fhqdefault.jpg",368,"368 views",{"id":166,"title":167,"description":7,"url":168,"thumbnail":169,"date":120,"dateLabel":121,"views":170,"viewsLabel":171,"category":33},"RcGUP2SkWzg","Into the woods! #trekking #trek #mumbai #Garbett","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=RcGUP2SkWzg","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FRcGUP2SkWzg\u002Fhqdefault.jpg",56,"56 views",{"id":173,"title":174,"description":7,"url":175,"thumbnail":176,"date":120,"dateLabel":121,"views":177,"viewsLabel":178,"category":33},"0R_9eH4svlM","Trek 01, Garbett Point Trek: A Day Hike With Amazing Views Near Mumbai","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=0R_9eH4svlM","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002F0R_9eH4svlM\u002Fhqdefault.jpg",49,"49 views",{"id":180,"title":181,"description":7,"url":182,"thumbnail":183,"date":184,"dateLabel":185,"views":186,"viewsLabel":187,"category":33},"kd2MJid5T2w","Bombay Monsoons are to live for!! ❤️🫶⛈️ #mumbai #monsoon #mumbaidiaries #marinedrive","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=kd2MJid5T2w","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002Fkd2MJid5T2w\u002Fhqdefault.jpg","2023-09-23T07:26:04.264Z","3 years ago",568,"568 views",{"id":189,"title":190,"description":7,"url":191,"thumbnail":192,"date":184,"dateLabel":185,"views":193,"viewsLabel":194,"category":33},"QvxC-l3IF3k","Magical Mornings at Marine Drive: Embrace the Tranquility #mumbai #marinedrive #trending #video","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=QvxC-l3IF3k","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FQvxC-l3IF3k\u002Fhqdefault.jpg",270,"270 views",{"id":196,"title":197,"description":7,"url":198,"thumbnail":199,"date":184,"dateLabel":185,"views":200,"viewsLabel":201,"category":33},"w6qxD5RVsgI","Mesmerizing #mumbai : Witness the Breathtaking Sunset at #marinedrive !","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=w6qxD5RVsgI","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002Fw6qxD5RVsgI\u002Fhqdefault.jpg",121,"121 views",{"id":203,"title":204,"description":7,"url":205,"thumbnail":206,"date":184,"dateLabel":185,"views":207,"viewsLabel":208,"category":42},"jM6eAwY2cF4","ChessTV, Game 02: Checkmate! Opponent quits as I dominate the Chessboard","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=jM6eAwY2cF4","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FjM6eAwY2cF4\u002Fhqdefault.jpg",51,"51 views",{"id":210,"title":211,"description":7,"url":212,"thumbnail":213,"date":184,"dateLabel":185,"views":214,"viewsLabel":215,"category":42},"jDoFBjzndmI","ChessTV, Game 01: The Agony of Defeat and Lessons Learned","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=jDoFBjzndmI","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FjDoFBjzndmI\u002Fhqdefault.jpg",29,"29 views",{"id":217,"title":218,"description":7,"url":219,"thumbnail":220,"date":184,"dateLabel":185,"views":221,"viewsLabel":222,"category":14},"fZtxvCBGuIo","The Philosophy of Cause and its Effect","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=fZtxvCBGuIo","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FfZtxvCBGuIo\u002Fhqdefault.jpg",45,"45 views",{"id":224,"title":225,"description":7,"url":226,"thumbnail":227,"date":184,"dateLabel":185,"views":228,"viewsLabel":229,"category":14},"8w9e1_gbyPE","Lady Sangeet Dance Video || Mom - Dad Duo || Cousin Wedding 2022","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=8w9e1_gbyPE","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002F8w9e1_gbyPE\u002Fhqdefault.jpg",0,"0 views",{"id":231,"title":232,"description":7,"url":233,"thumbnail":234,"date":235,"dateLabel":236,"views":228,"viewsLabel":229,"category":100},"-ivhSFGyGuI","Video Resume | HighRadius | Winter Internship 2021","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=-ivhSFGyGuI","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002F-ivhSFGyGuI\u002Fhqdefault.jpg","2022-09-23T07:26:04.264Z","4 years ago",{"id":238,"title":239,"description":7,"url":240,"thumbnail":241,"date":235,"dateLabel":236,"views":242,"viewsLabel":243,"category":100},"CZXqEZX_V94","Campus Placement | A Data Mining Solution to Predict Campus Placement | GUCON 2021 | Research Paper","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=CZXqEZX_V94","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FCZXqEZX_V94\u002Fhqdefault.jpg",92,"92 views",{"id":245,"title":246,"description":7,"url":247,"thumbnail":248,"date":249,"dateLabel":250,"views":251,"viewsLabel":252,"category":100},"jPMxuAxcpAY","CodeChef || December Challenge 2020 Division 2 - DEC20B || Even Pair Sum-EVENPSUM","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=jPMxuAxcpAY","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FjPMxuAxcpAY\u002Fhqdefault.jpg","2021-09-23T07:26:04.264Z","5 years ago",357,"357 views",{"id":254,"title":255,"description":7,"url":256,"thumbnail":257,"date":249,"dateLabel":250,"views":258,"viewsLabel":259,"category":100},"PY-jAABcgbU","Codechef || December Challenge 2020 Division 2 - DEC20B || Vaccine Production-VACCINE1","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=PY-jAABcgbU","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FPY-jAABcgbU\u002Fhqdefault.jpg",279,"279 views",[261,277,286,296,305,315,320,332,336,345,353,365,373,382],{"slug":262,"title":263,"excerpt":264,"topic":265,"platform":266,"url":267,"xUrl":268,"substackUrl":269,"date":270,"dateLabel":271,"year":272,"readTime":273,"cover":274,"content":275,"full":276},"your-folder-structure-is-lying-to-you","Your Folder Structure Is Lying to You","The way most developers organize a full-stack project creates problems that don’t show up until it’s too late to fix them. Continue reading on JavaScript in Plain English »","engineering","Medium","https:\u002F\u002Fjavascript.plainenglish.io\u002Fyour-folder-structure-is-lying-to-you-257e90e115ef","https:\u002F\u002Fx.com\u002Fjainprayush9\u002Fstatus\u002F2102061118474899683",null,"2026-09-21T14:42:59.000Z","Sep 21, 2026",2026,"7 min","\u002Fimages\u002Fessays\u002Ffolder-structure\u002Fcover.png","\u003Cfigure class=\"essay-figure\">\u003Cimg src=\"\u002Fimages\u002Fessays\u002Ffolder-structure\u002Fcover.png\" alt=\"Full Stack Web Development — folder structure overview\" loading=\"lazy\" \u002F>\u003Cfigcaption>Full Stack Web Development — folder structure overview\u003C\u002Ffigcaption>\u003C\u002Ffigure>\n\u003Cp>The way most developers organize a full-stack project creates problems that don’t show up until it’s too late to fix them.\u003C\u002Fp>\n\u003Cp>I’ve worked on codebases that were a joy to navigate and codebases that made me genuinely anxious every time I had to add a feature.\u003C\u002Fp>\n\u003Cp>The difference was rarely the technology. It was the folder structure.\u003C\u002Fp>\n\u003Cp>A bad structure doesn’t announce itself on day one. It feels fine when there are 10 files. It gets uncomfortable around 50. By 200 files, you’re spending more time hunting for things than actually building them. And by then, the cost of fixing it is so high that most teams just accept the mess and move on.\u003C\u002Fp>\n\u003Cp>The right structure, on the other hand, disappears. You stop thinking about where files go. New developers onboard faster. Features live where you expect them to live. The codebase becomes something you’re proud to show people.\u003C\u002Fp>\n\u003Cp>Here’s what that looks like — for both frontend and backend, in a modern full-stack project.\u003C\u002Fp>\n\u003Ch2>First Decision: Monorepo or Multi-Repo?\u003C\u002Fh2>\n\u003Cp>Before you write a single line of code, you need to decide whether your frontend and backend live in the same repository or separate ones.\u003C\u002Fp>\n\u003Cp>Most teams default to separate repos without thinking about it. That’s often the wrong call.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Choose a monorepo when:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\u003Cli>Your team is 2–10 developers\u003C\u002Fli>\u003Cli>Frontend and backend share types, validation schemas, or business logic\u003C\u002Fli>\u003Cli>You deploy frontend and backend together\u003C\u002Fli>\u003Cli>You want a single place for CI\u002FCD, linting, and tooling\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Choose multi-repo when:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\u003Cli>You have separate teams with clear ownership boundaries\u003C\u002Fli>\u003Cli>Frontend and backend have completely independent deployment cycles\u003C\u002Fli>\u003Cli>You’re running microservices with different tech stacks\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>For most product teams building a standard web application, a monorepo is the right call. The shared code benefits alone are worth it. The rest of this article assumes a monorepo setup.\u003C\u002Fp>\n\u003Ch2>The Root Structure\u003C\u002Fh2>\n\u003Cp>Start clean at the root level. Everything has a home, nothing is ambiguous:\u003C\u002Fp>\n\u003Cpre data-lang=\"text\">\u003Ccode>my-project\u002F\n├── frontend\u002F          # All frontend code\n├── backend\u002F           # All backend code\n├── shared\u002F            # Shared types, utils, constants\n├── docs\u002F              # Documentation\n├── scripts\u002F           # Build, deployment, utility scripts\n├── docker\u002F            # Docker configurations\n├── .github\u002F           # CI\u002FCD workflows\n├── package.json       # Root package.json for workspace management\n├── README.md\n└── .gitignore\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>The \u003Ccode>shared\u002F\u003C\u002Fcode> folder is the part most people skip. It’s also the part that saves you the most pain — more on that later.\u003C\u002Fp>\n\u003Ch2>Frontend Structure: Organize by Feature, Not by File Type\u003C\u002Fh2>\n\u003Cp>This is where most projects go wrong.\u003C\u002Fp>\n\u003Cp>The instinct is to organize by what a file \u003Cem>is\u003C\u002Fem> — a component, a service, a hook, a type. So you end up with:\u003C\u002Fp>\n\u003Cpre data-lang=\"text\">\u003Ccode>src\u002F\n├── components\u002F\n├── services\u002F\n├── hooks\u002F\n├── types\u002F\n└── pages\u002F\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>This looks clean on day one. By month three, your \u003Ccode>components\u002F\u003C\u002Fcode> folder has 80 files in it, and nobody remembers what half of them do or which page uses them.\u003C\u002Fp>\n\u003Cp>Organize by feature instead. Every feature owns its own components, services, hooks, and types:\u003C\u002Fp>\n\u003Cpre data-lang=\"text\">\u003Ccode>frontend\u002F\n├── public\u002F\n├── src\u002F\n│   ├── apps\u002F                  # Feature-based modules\n│   │   ├── dashboard\u002F\n│   │   ├── auth\u002F\n│   │   └── admin\u002F\n│   ├── shared\u002F                # Code shared across features\n│   │   ├── components\u002F        # Reusable UI components\n│   │   ├── hooks\u002F             # Shared custom hooks\n│   │   ├── utils\u002F             # Utility functions\n│   │   ├── types\u002F             # Global TypeScript types\n│   │   ├── constants\u002F         # App-wide constants\n│   │   ├── styles\u002F            # Global styles and themes\n│   │   └── services\u002F          # API clients\n│   ├── assets\u002F\n│   ├── router\u002F\n│   ├── store\u002F\n│   └── main.ts\n├── tests\u002F\n├── package.json\n├── vite.config.ts\n└── tsconfig.json\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Here’s what a single feature looks like internally:\u003C\u002Fp>\n\u003Cpre data-lang=\"text\">\u003Ccode>src\u002Fapps\u002Fuser-management\u002F\n├── components\u002F\n│   ├── UserList.vue\n│   ├── UserForm.vue\n│   └── UserCard.vue\n├── services\u002F\n│   └── userApi.ts\n├── types\u002F\n│   └── user.types.ts\n└── pages\u002F\n    ├── UsersPage.vue\n    └── UserDetailPage.vue\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Everything related to user management lives in one place. When you delete a feature, you delete one folder. When you debug a feature, you look in one folder. The mental overhead drops dramatically.\u003C\u002Fp>\n\u003Ch2>Build a Shared Component Library\u003C\u002Fh2>\n\u003Cp>Reusable UI components deserve their own structure — not just a flat list of files:\u003C\u002Fp>\n\u003Cpre data-lang=\"text\">\u003Ccode>src\u002Fshared\u002Fcomponents\u002F\n├── Button\u002F\n│   ├── Button.vue\n│   ├── Button.types.ts\n│   ├── Button.stories.ts\n│   └── index.ts\n├── Card\u002F\n├── Modal\u002F\n└── index.ts        # Barrel exports\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Each component is self-contained: its implementation, its types, and its stories all live together. The \u003Ccode>index.ts\u003C\u002Fcode> barrel export means your imports stay clean no matter where you are in the project.\u003C\u002Fp>\n\u003Ch2>Set Up Path Aliases Early\u003C\u002Fh2>\n\u003Cp>Do this before you write more than 10 files. Relative imports (\u003Ccode>..\u002F..\u002Fshared\u002Fcomponents\u003C\u002Fcode>) turn into archaeology projects at scale.\u003C\u002Fp>\n\u003Cpre data-lang=\"ts\">\u003Ccode>\u002F\u002F vite.config.ts\nexport default defineConfig({\n  resolve: {\n    alias: {\n      '@': resolve(__dirname, '.\u002Fsrc'),\n      '@shared': resolve(__dirname, '.\u002Fsrc\u002Fshared'),\n      '@apps': resolve(__dirname, '.\u002Fsrc\u002Fapps'),\n      '@components': resolve(__dirname, '.\u002Fsrc\u002Fshared\u002Fcomponents')\n    }\n  }\n})\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Now instead of \u003Ccode>..\u002F..\u002Fshared\u002Fcomponents\u002FButton\u003C\u002Fcode>, you write \u003Ccode>@components\u002FButton\u003C\u002Fcode>. Refactoring paths becomes a non-issue.\u003C\u002Fp>\n\u003Ch2>Backend Structure: Make the Layers Obvious\u003C\u002Fh2>\n\u003Cp>The most maintainable backend codebases have clear separation between three things:\u003C\u002Fp>\n\u003Col>\u003Cli>What the HTTP layer does (receiving requests, sending responses)\u003C\u002Fli>\u003Cli>What the business logic does (the actual rules of your application)\u003C\u002Fli>\u003Cli>What the data layer does (talking to the database)\u003C\u002Fli>\u003C\u002Fol>\n\u003Cp>When these are muddled together, you end up with controllers that contain business logic, services that write raw SQL, and models that send emails. It’s a mess that is very easy to fall into and very hard to get out of.\u003C\u002Fp>\n\u003Cp>The structure that enforces this separation:\u003C\u002Fp>\n\u003Cpre data-lang=\"text\">\u003Ccode>backend\u002F\n├── src\u002F\n│   ├── controllers\u002F     # HTTP request handlers — nothing else\n│   ├── services\u002F        # Business logic — nothing else\n│   ├── repositories\u002F    # Data access — nothing else\n│   ├── models\u002F          # Data models and entities\n│   ├── middleware\u002F      # Express middleware\n│   ├── routes\u002F          # Route definitions\n│   ├── utils\u002F           # Utility functions\n│   ├── types\u002F           # TypeScript types\n│   ├── config\u002F          # Configuration\n│   ├── validators\u002F      # Request validation schemas\n│   └── app.ts\n├── tests\u002F\n├── migrations\u002F\n├── seeds\u002F\n├── docs\u002F\n├── package.json\n└── tsconfig.json\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2>Go Domain-Driven at Scale\u003C\u002Fh2>\n\u003Cp>For larger applications with multiple product areas, the flat structure above starts to blur. Switch to domain-driven organization:\u003C\u002Fp>\n\u003Cpre data-lang=\"text\">\u003Ccode>backend\u002Fsrc\u002F\n├── domains\u002F\n│   ├── user\u002F\n│   │   ├── user.controller.ts\n│   │   ├── user.service.ts\n│   │   ├── user.repository.ts\n│   │   ├── user.model.ts\n│   │   ├── user.types.ts\n│   │   └── user.routes.ts\n│   ├── product\u002F\n│   └── order\u002F\n├── shared\u002F\n│   ├── middleware\u002F\n│   ├── utils\u002F\n│   └── types\u002F\n└── infrastructure\u002F\n    ├── database\u002F\n    ├── cache\u002F\n    └── external-apis\u002F\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Same principle as the frontend feature structure: everything related to a domain lives together. A new developer can open \u003Ccode>domains\u002Fuser\u002F\u003C\u002Fcode> and understand the entire user feature without touching anything else.\u003C\u002Fp>\n\u003Ch2>The Shared Folder: The Part That Ties It All Together\u003C\u002Fh2>\n\u003Cp>This is the folder most people skip, and it is the one that causes the most pain when it’s missing.\u003C\u002Fp>\n\u003Cp>In a monorepo, your frontend and backend share more than you think:\u003C\u002Fp>\n\u003Cul>\u003Cli>TypeScript types for API request\u002Fresponse shapes\u003C\u002Fli>\u003Cli>Validation schemas (Zod, Joi) that should match on both sides\u003C\u002Fli>\u003Cli>Error codes that the frontend needs to handle\u003C\u002Fli>\u003Cli>Constants that need to be consistent everywhere\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Without a shared folder, these end up duplicated. The frontend defines a \u003Ccode>User\u003C\u002Fcode> type. The backend defines a slightly different \u003Ccode>User\u003C\u002Fcode> type. Six months later, a field name changes on one side and nobody updates the other, and you spend a Friday debugging a bug that should have been a type error.\u003C\u002Fp>\n\u003Cpre data-lang=\"text\">\u003Ccode>shared\u002F\n├── types\u002F\n│   ├── api.types.ts         # API request\u002Fresponse shapes\n│   ├── user.types.ts\n│   └── common.types.ts\n├── constants\u002F\n│   ├── api-endpoints.ts\n│   ├── error-codes.ts\n│   └── app-config.ts\n├── utils\u002F\n│   ├── validation.ts\n│   ├── formatters.ts\n│   └── date-utils.ts\n└── schemas\u002F                 # Zod\u002FJoi validation schemas\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>A shared API type looks like this:\u003C\u002Fp>\n\u003Cpre data-lang=\"ts\">\u003Ccode>\u002F\u002F shared\u002Ftypes\u002Fapi.types.ts\nexport interface ApiResponse<T> {\n  data: T;\n  message: string;\n  success: boolean;\n  timestamp: string;\n}\n\nexport interface PaginatedResponse<T> extends ApiResponse<T[]> {\n  pagination: {\n    page: number;\n    limit: number;\n    total: number;\n    totalPages: number;\n  };\n}\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Both frontend and backend import from the same source. One type to update, zero inconsistencies.\u003C\u002Fp>\n\u003Ch2>The Rule That Ties It All Together\u003C\u002Fh2>\n\u003Cp>If I had to reduce all of this to a single principle, it’s this:\u003C\u002Fp>\n\u003Cp>\u003Cstrong>A file should live where the person looking for it will look first.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>Not where it technically belongs in some abstract taxonomy. Not where it’s easiest to put it right now. Where someone — including future-you, six months from now — will naturally go to find it.\u003C\u002Fp>\n\u003Cp>Feature-based organization wins because that’s how humans think about software. You think “I need to change something about user management” — not “I need to find a component file.”\u003C\u002Fp>\n\u003Cp>Layered backend organization wins because when something breaks, you think “this is a data problem” or “this is a logic problem” or “this is a routing problem” — and the layers let you go directly to the right place.\u003C\u002Fp>\n\u003Cp>The folder structure is not the code. But it is the map. And a bad map costs you more time than almost anything else.\u003C\u002Fp>\n\u003Cp>Get the map right first.\u003C\u002Fp>",true,{"slug":278,"title":279,"excerpt":280,"topic":14,"platform":266,"url":281,"xUrl":269,"substackUrl":269,"date":282,"dateLabel":271,"year":272,"readTime":283,"cover":284,"content":285,"full":276},"the-flag-we-never-really-look-at","The Flag We Never Really Look At","Every Independence Day, we hoist it, photograph it, and post it. Most of us have no idea how many times it almost looked completely… Continue reading on Medium »","https:\u002F\u002Fjainprayush9.medium.com\u002Fthe-flag-we-never-really-look-at-4acff63a2070","2026-09-21T14:40:53.000Z","5 min","\u002Fimages\u002Fessays\u002Fflag\u002Fcover.jpg","\u003Cfigure class=\"essay-figure\">\u003Cimg src=\"\u002Fimages\u002Fessays\u002Fflag\u002Fcover.jpg\" alt=\"The Indian flag — saffron, white, green, and the Ashoka Chakra\" loading=\"lazy\" \u002F>\u003Cfigcaption>The Indian flag — saffron, white, green, and the Ashoka Chakra\u003C\u002Ffigcaption>\u003C\u002Ffigure>\n\u003Cp>Every Independence Day, we hoist it, photograph it, and post it. Most of us have no idea how many times it almost looked completely different.\u003C\u002Fp>\n\u003Cp>You’ve seen it thousands of times.\u003C\u002Fp>\n\u003Cp>On government buildings, on cricket jerseys, on WhatsApp forwards every August 15th. You know the colors — saffron, white, green. You know the wheel in the middle. You could draw it from memory.\u003C\u002Fp>\n\u003Cp>But do you know what it took to get here?\u003C\u002Fp>\n\u003Cp>The Indian flag we recognize today didn’t arrive fully formed at independence. It went through nearly five decades of argument, iteration, and redesign — shaped by revolutionaries, spiritual leaders, political movements, and ultimately, a nation trying to define itself before it even existed.\u003C\u002Fp>\n\u003Cp>Here’s the real story.\u003C\u002Fp>\n\u003Ch2>It Started With a Nun\u003C\u002Fh2>\n\u003Cp>The first version of what could be called India’s national flag was designed in 1904 — not by a politician, but by Sister Nivedita, an Irish-born disciple of Swami Vivekananda who had given her life to India’s cause.\u003C\u002Fp>\n\u003Cp>Her flag was a bold red and yellow tricolor, carrying a vajra (thunderbolt) and the Bengali words for “Hail to the Motherland” at its center. It wasn’t widely adopted, but it planted a seed: India needed a flag. Not just a symbol of a movement, but of a nation.\u003C\u002Fp>\n\u003Cp>The idea refused to die.\u003C\u002Fp>\n\u003Ch2>The Swadeshi Experiment\u003C\u002Fh2>\n\u003Cp>During the Swadeshi Movement of the early 1900s, as Indians began boycotting British goods and demanding self-rule, a new flag emerged — one that tried to solve a uniquely Indian problem.\u003C\u002Fp>\n\u003Cp>How do you represent a country with Hindus, Muslims, Sikhs, Christians, Parsis, and dozens of other communities under a single symbol?\u003C\u002Fp>\n\u003Cp>The answer, at the time, was to put everyone in. The flag used horizontal stripes of red, yellow, and green — and included symbols representing different religious communities. It was a well-intentioned attempt at unity.\u003C\u002Fp>\n\u003Cp>It was also too crowded to work as a national symbol.\u003C\u002Fp>\n\u003Cp>But the instinct behind it — unity in diversity — would survive and eventually become the defining principle of whatever flag India chose.\u003C\u002Fp>\n\u003Ch2>Gandhi’s Proposal\u003C\u002Fh2>\n\u003Cp>The flag that really changed everything came in 1921, when Mahatma Gandhi walked into the All India Congress Committee meeting with a proposal.\u003C\u002Fp>\n\u003Cp>Three equal horizontal stripes:\u003C\u002Fp>\n\u003Cul>\u003Cli>Saffron at the top\u003C\u002Fli>\u003Cli>White in the middle\u003C\u002Fli>\u003Cli>Green at the bottom\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>And at the center — a spinning wheel, the charkha.\u003C\u002Fp>\n\u003Cp>The charkha wasn’t just a symbol. It was a statement. Gandhi saw it as the heartbeat of India’s independence strategy: if every Indian household spun their own cloth, they could break economic dependence on Britain. The flag, in his vision, wasn’t decorative. It was a call to action.\u003C\u002Fp>\n\u003Cp>The Congress adopted it. For the next two decades, this was the flag of the independence movement — carried in protests, raised at meetings, torn down by British authorities, and raised again.\u003C\u002Fp>\n\u003Ch2>The Final Change: The Wheel of Dharma\u003C\u002Fh2>\n\u003Cp>When India finally gained independence in 1947, one last decision remained.\u003C\u002Fp>\n\u003Cp>The charkha — Gandhi’s spinning wheel — was removed from the center. In its place came the Ashoka Chakra: a 24-spoke navy blue wheel drawn from the Lion Capital of Emperor Ashoka, the Mauryan ruler who had governed most of the Indian subcontinent in the 3rd century BC, and who had chosen dharma — righteousness — over conquest after witnessing the devastation of war.\u003C\u002Fp>\n\u003Cp>This was a deliberate choice. The spinning wheel looked backward, toward economic self-reliance. The Ashoka Chakra looked forward — and outward — toward India’s place in the world. It carried a different message: not just self-sufficiency, but justice, progress, and the continuous motion of a civilizational ideal.\u003C\u002Fp>\n\u003Cp>Gandhi was reportedly unhappy with the change. He had wanted the charkha on the flag of free India.\u003C\u002Fp>\n\u003Cp>But the constituent assembly had made its decision. On July 22, 1947 — weeks before independence — the tricolor with the Ashoka Chakra was officially adopted as the national flag of India.\u003C\u002Fp>\n\u003Ch2>What the Colors Actually Mean\u003C\u002Fh2>\n\u003Cp>The three colors are not arbitrary. Each carries a specific meaning that was debated and chosen carefully:\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Saffron\u003C\u002Fstrong> — Courage, sacrifice, and the spirit of renunciation. The saffron of Indian ascetics and warriors, of people who gave up personal comfort for something larger.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>White\u003C\u002Fstrong> — Peace, truth, and the path of righteousness. Not just the absence of conflict, but the active pursuit of honesty in how the nation governs itself.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Green\u003C\u002Fstrong> — Fertility, growth, and the land itself. India was, and remains, an agricultural civilization — a country whose prosperity has always been tied to the earth.\u003C\u002Fp>\n\u003Cp>The Ashoka Chakra in navy blue sits at the intersection of all three. Its 24 spokes represent the 24 hours of the day — a reminder that the wheel of dharma never stops turning.\u003C\u002Fp>\n\u003Ch2>The Flag as a Living Document\u003C\u002Fh2>\n\u003Cp>What’s remarkable about the evolution of the Indian flag isn’t just the history. It’s what that history reveals about the people who shaped it.\u003C\u002Fp>\n\u003Cp>Sister Nivedita, a foreigner who loved India more than many of its own citizens were allowed to. Gandhi, who wanted a symbol of economic revolt, not just political independence. The architects of the constitution, who chose the wisdom of Ashoka — an emperor who renounced violence — as the visual centerpiece of a newly free nation.\u003C\u002Fp>\n\u003Cp>Every iteration of the flag was an argument about what India should be. Not just what it was, or what it had suffered, but what it was trying to become.\u003C\u002Fp>\n\u003Cp>That argument didn’t end in 1947. It’s still happening.\u003C\u002Fp>\n\u003Cp>Every time we talk about what it means to be Indian — in conversations about religion, language, history, democracy — we are continuing the same discussion that produced those three colors and that wheel.\u003C\u002Fp>\n\u003Cp>The flag isn’t just a symbol of what was built.\u003C\u002Fp>\n\u003Cp>It’s a question we’re still answering.\u003C\u002Fp>\n\u003Cp>Happy Independence Day. 🇮🇳\u003C\u002Fp>\n\u003Cp>I write about India, culture, and the stories we carry. Find me on \u003Ca href=\"https:\u002F\u002Fx.com\u002Fjainprayush9\" target=\"_blank\" rel=\"noopener noreferrer\">X\u003C\u002Fa> and \u003Ca href=\"https:\u002F\u002Fyoutube.com\u002F@jainprayush9\" target=\"_blank\" rel=\"noopener noreferrer\">YouTube\u003C\u002Fa>.\u003C\u002Fp>",{"slug":287,"title":288,"excerpt":289,"topic":265,"platform":266,"url":290,"xUrl":269,"substackUrl":269,"date":291,"dateLabel":292,"year":272,"readTime":293,"cover":294,"content":295,"full":276},"most-people-use-claude-like-a-search-engine-thats-why-they-re-disappointed","Most People Use Claude Like a Search Engine. That’s Why They’re Disappointed.","The difference between getting mediocre AI output and genuinely useful output isn’t the tool. It’s how you think about the conversation. Continue reading on Medium »","https:\u002F\u002Fjainprayush9.medium.com\u002Fmost-people-use-claude-like-a-search-engine-thats-why-they-re-disappointed-4fc29038fc3c","2026-09-19T11:59:13.000Z","Sep 19, 2026","8 min","\u002Fimages\u002Fessays\u002Fclaude-search\u002Fcover.jpg","\u003Cfigure class=\"essay-figure\">\u003Cimg src=\"\u002Fimages\u002Fessays\u002Fclaude-search\u002Fcover.jpg\" alt=\"Claude AI — reasoning with context, not search\" loading=\"lazy\" \u002F>\u003Cfigcaption>Claude AI — reasoning with context, not search\u003C\u002Ffigcaption>\u003C\u002Ffigure>\n\u003Cp>The difference between getting mediocre AI output and genuinely useful output isn’t the tool. It’s how you think about the conversation.\u003C\u002Fp>\n\u003Cp>Everyone has the same complaint about AI.\u003C\u002Fp>\n\u003Cp>“It gives me generic answers.” “It sounds robotic.” “It doesn’t understand what I actually need.” “I asked it to write something and it was terrible.”\u003C\u002Fp>\n\u003Cp>And then these same people type: “Write me an email about the meeting” — and wonder why what comes back is useless.\u003C\u002Fp>\n\u003Cp>Claude, like any powerful tool, rewards people who understand how it works. The people getting extraordinary output from it are not using magic prompts. They are using a different mental model entirely. And once you see it, you cannot unsee it.\u003C\u002Fp>\n\u003Cp>Here is that mental model — and the specific ways to apply it.\u003C\u002Fp>\n\u003Ch2>The Core Mistake: Treating Claude Like a Vending Machine\u003C\u002Fh2>\n\u003Cp>Most people approach Claude the same way they approach Google. They have a need. They type it in. They expect an output. If the output is bad, they either accept it or give up.\u003C\u002Fp>\n\u003Cp>This is exactly wrong.\u003C\u002Fp>\n\u003Cp>Google is a retrieval engine. You give it keywords; it finds existing information. The quality of its output depends on what already exists on the internet, not on how you talk to it.\u003C\u002Fp>\n\u003Cp>Claude is a reasoning engine. The quality of its output depends almost entirely on the quality of the context you give it. The same question, asked with different context, can produce output that is either useless or genuinely impressive — from the same model, in the same conversation.\u003C\u002Fp>\n\u003Cp>The shift is this: stop thinking of Claude as a vending machine where you insert a query and collect a result. Start thinking of it as a smart colleague who just joined the room and knows nothing about what you’re working on.\u003C\u002Fp>\n\u003Cp>How much would you explain to that colleague before asking them to help you?\u003C\u002Fp>\n\u003Cp>That’s how much context Claude needs.\u003C\u002Fp>\n\u003Ch2>1. Tell Claude Who It Is and What You’re Trying to Achieve\u003C\u002Fh2>\n\u003Cp>Before you ask Claude to do anything, give it a role and a goal.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Weak prompt:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>“Write a cold email to a potential client.”\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Strong prompt:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>“You are a B2B sales consultant with 10 years of experience selling SaaS products to mid-size companies. I need to write a cold email to a VP of Marketing at a fintech company. My product helps with customer retention analytics. The goal isn’t to close a deal — it’s to get a 20-minute call. Write an email that feels human, not templated.”\u003C\u002Fp>\n\u003Cp>The second prompt is longer. It takes 30 extra seconds to write. The output is incomparably better — because Claude now knows the lens through which to approach the problem.\u003C\u002Fp>\n\u003Cp>A useful rule: \u003Cstrong>role + context + goal + constraint.\u003C\u002Fstrong> Use all four whenever you want high-quality output.\u003C\u002Fp>\n\u003Cul>\u003Cli>\u003Cstrong>Role:\u003C\u002Fstrong> Who is Claude in this conversation?\u003C\u002Fli>\u003Cli>\u003Cstrong>Context:\u003C\u002Fstrong> What is the situation?\u003C\u002Fli>\u003Cli>\u003Cstrong>Goal:\u003C\u002Fstrong> What does success look like?\u003C\u002Fli>\u003Cli>\u003Cstrong>Constraint:\u003C\u002Fstrong> What should it avoid or stay within?\u003C\u002Fli>\u003C\u002Ful>\n\u003Ch2>2. Give Examples, Not Just Instructions\u003C\u002Fh2>\n\u003Cp>Claude learns what you want far faster from examples than from descriptions.\u003C\u002Fp>\n\u003Cp>If you want Claude to write in your voice, paste three samples of your own writing before asking it to write anything. If you want it to format output a specific way, show it an example of that format. If you want it to match a tone, give it a reference.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Without example:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>“Write a LinkedIn post about what I learned from my last project.”\u003C\u002Fp>\n\u003Cp>\u003Cstrong>With example:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>“Here’s how I typically write LinkedIn posts: [paste your actual post]. Write a new one about what I learned from shipping a feature that failed in testing but worked in production. Same energy, same length.”\u003C\u002Fp>\n\u003Cp>The difference in output will shock you every time.\u003C\u002Fp>\n\u003Cp>This works because Claude is pattern-matching what you show it, not just parsing your instructions abstractly. Instructions describe what you want. Examples demonstrate it. Demonstration beats description almost every time.\u003C\u002Fp>\n\u003Ch2>3. Push Back. Claude Gets Better When You Do.\u003C\u002Fh2>\n\u003Cp>This mistake quietly costs people the most value.\u003C\u002Fp>\n\u003Cp>Claude produces output. The output is 70% there. Most people either accept the 70% and move on, or they start over with a new prompt. Both are wrong.\u003C\u002Fp>\n\u003Cp>The right move is to push back in the same conversation.\u003C\u002Fp>\n\u003Cp>“This is good but it’s too formal. Make it conversational — the kind of thing I’d say to a friend, not a client.”\u003C\u002Fp>\n\u003Cp>“The second paragraph is the strongest. Rewrite the rest to match that energy.”\u003C\u002Fp>\n\u003Cp>“You’ve given me the obvious answer. What’s the non-obvious version that most people would miss?”\u003C\u002Fp>\n\u003Cp>Claude doesn’t get offended. It doesn’t take feedback personally. It recalibrates based on your pushback and produces a better version. The conversation is the product — not the first response.\u003C\u002Fp>\n\u003Cp>The people who get the best output from Claude treat the first response as a draft, not a deliverable.\u003C\u002Fp>\n\u003Ch2>4. Ask Claude to Think Before It Answers\u003C\u002Fh2>\n\u003Cp>For anything requiring analysis, reasoning, or judgment — ask Claude to think through the problem before it gives you the answer.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Without this:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>“Should I take this job offer?”\u003C\u002Fp>\n\u003Cp>\u003Cstrong>With this:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>“I’m deciding whether to take a job offer. Before you give me an opinion, walk me through the key questions I should be asking myself. Then help me think through each one.”\u003C\u002Fp>\n\u003Cp>When you ask Claude to reason out loud, two things happen. First, the answer gets better — because the model is working through the problem rather than pattern-matching to the most common answer. Second, you often realize what you actually want while reading the reasoning, before you even get to the conclusion.\u003C\u002Fp>\n\u003Cp>This technique — sometimes called chain-of-thought prompting — is especially powerful for:\u003C\u002Fp>\n\u003Cul>\u003Cli>Decisions with multiple variables\u003C\u002Fli>\u003Cli>Problems where you’re not sure what the real question is\u003C\u002Fli>\u003Cli>Situations where you want to pressure-test your own thinking\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>A simple trigger phrase: “Think through this step by step before answering.” Add it to almost any complex prompt and watch the output quality jump.\u003C\u002Fp>\n\u003Ch2>5. Use Claude to Think, Not Just to Produce\u003C\u002Fh2>\n\u003Cp>Most people use Claude as a production tool. Write this. Summarize that. Generate a list.\u003C\u002Fp>\n\u003Cp>The people getting the most out of it use it as a thinking tool.\u003C\u002Fp>\n\u003Cp>There is a meaningful difference.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Production mode:\u003C\u002Fstrong> “Write a strategy for growing my newsletter.”\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Thinking mode:\u003C\u002Fstrong> “I’m trying to grow my newsletter from 500 to 5,000 subscribers in six months. Here’s what I’ve tried so far: [context]. What assumptions am I making that might be wrong? What am I probably not seeing?”\u003C\u002Fp>\n\u003Cp>The second approach doesn’t ask Claude to produce an answer. It asks Claude to challenge your thinking. To find the holes. To bring the perspective you don’t have because you’re too close to the problem.\u003C\u002Fp>\n\u003Cp>This is genuinely hard to get from another human. Your friends and colleagues have social incentives to agree with you, or to soften their criticism. Claude has no such incentive. If you ask it to find what’s wrong with your plan, it will find what’s wrong with your plan.\u003C\u002Fp>\n\u003Cp>Use that.\u003C\u002Fp>\n\u003Ch2>6. Give Claude Your Constraints, Not Just Your Goal\u003C\u002Fh2>\n\u003Cp>One of the most common reasons Claude produces unhelpful output is that it doesn’t know your constraints — so it optimizes for a version of the problem you don’t actually have.\u003C\u002Fp>\n\u003Cp>If you need a response in under 100 words, say so. If you can’t use technical jargon because your audience is non-technical, say so. If you have a budget limit, a timeline, a format requirement, a brand guideline — say so upfront, not as a correction after the fact.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Without constraints:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>“Help me plan a team offsite.”\u003C\u002Fp>\n\u003Cp>\u003Cstrong>With constraints:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>“Help me plan a one-day team offsite for 12 people. Budget is ₹50,000. Everyone is based in Bangalore. The goal is team bonding, not work — we want people to leave feeling energized, not like they sat through more meetings. Half the team is introverted. Suggest a format that doesn’t force everyone to perform extroversion.”\u003C\u002Fp>\n\u003Cp>The second prompt gets you something you can actually use. The first gets you a generic event agenda.\u003C\u002Fp>\n\u003Cp>Constraints are not limitations on creativity. They are the parameters that make the output relevant to your actual situation. The more honestly you share them, the better Claude serves you.\u003C\u002Fp>\n\u003Ch2>7. Have the Conversation, Not Just the Prompt\u003C\u002Fh2>\n\u003Cp>The single biggest unlock most people are missing: Claude has memory within a conversation.\u003C\u002Fp>\n\u003Cp>Most people use Claude like a one-shot interaction. They type a prompt, get a response, and either leave or start fresh. This throws away the most valuable thing about conversational AI — the context that builds over an exchange.\u003C\u002Fp>\n\u003Cp>When you stay in a conversation, Claude carries forward everything it has learned about your situation, your preferences, your constraints, and your feedback. The fifth message in a conversation is almost always better than the first — because by then Claude understands what you actually want.\u003C\u002Fp>\n\u003Cp>A practical workflow that works:\u003C\u002Fp>\n\u003Col>\u003Cli>Open with context — who you are, what you’re working on, what you need\u003C\u002Fli>\u003Cli>Ask your first question\u003C\u002Fli>\u003Cli>Push back on anything that’s off\u003C\u002Fli>\u003Cli>Ask follow-up questions that build on the previous answer\u003C\u002Fli>\u003Cli>At any point, you can say “summarize what we’ve decided so far” to consolidate\u003C\u002Fli>\u003C\u002Fol>\n\u003Cp>Treat it like a working session with a colleague, not a one-off transaction with a search engine.\u003C\u002Fp>\n\u003Ch2>The Underlying Principle\u003C\u002Fh2>\n\u003Cp>Everything above comes back to one idea: Claude is only as good as the conversation you bring to it.\u003C\u002Fp>\n\u003Cp>The tool is not the bottleneck. Your willingness to give it context, push back on what’s wrong, ask it to think rather than just answer, and stay in the conversation long enough for it to actually understand what you need — that is the bottleneck.\u003C\u002Fp>\n\u003Cp>The people who say AI doesn’t work are usually the people who gave it a vague one-line prompt, got a generic response, and concluded the technology is overhyped.\u003C\u002Fp>\n\u003Cp>The people who say AI changed how they work are usually the people who figured out that it rewards effort. Not effort in the traditional sense — not hours of labor — but the effort of thinking clearly about what you want and communicating it well.\u003C\u002Fp>\n\u003Cp>That’s a skill. And like most skills, it compounds the more you practice it.\u003C\u002Fp>\n\u003Cp>Start with one conversation today. Give it context. Push back. Stay in it.\u003C\u002Fp>\n\u003Cp>See what happens.\u003C\u002Fp>\n\u003Cp>I write about building, creating, and working smarter — from someone still figuring it out. Find me on \u003Ca href=\"https:\u002F\u002Fx.com\u002Fjainprayush9\" target=\"_blank\" rel=\"noopener noreferrer\">X\u003C\u002Fa> and \u003Ca href=\"https:\u002F\u002Fyoutube.com\u002F@jainprayush9\" target=\"_blank\" rel=\"noopener noreferrer\">YouTube\u003C\u002Fa>.\u003C\u002Fp>",{"slug":297,"title":298,"excerpt":299,"topic":14,"platform":266,"url":300,"xUrl":269,"substackUrl":269,"date":301,"dateLabel":292,"year":272,"readTime":302,"cover":303,"content":304,"full":276},"the-show-that-taught-india-to-shout","The Show That Taught India to Shout","19 seasons, 500 million viewers, and the quiet normalization of everything wrong with how we treat each other. Continue reading on The Rabbit Note »","https:\u002F\u002Fmedium.com\u002Fthe-rabbit-note\u002Fthe-show-that-taught-india-to-shout-cd2e46a809bc","2026-09-19T09:52:38.000Z","11 min","\u002Fimages\u002Fessays\u002Fbigg-boss\u002Fcover.png","\u003Cfigure class=\"essay-figure\">\u003Cimg src=\"\u002Fimages\u002Fessays\u002Fbigg-boss\u002Fcover.png\" alt=\"Bigg Boss — Salman Khan and the franchise eye\" loading=\"lazy\" \u002F>\u003Cfigcaption>Bigg Boss — Salman Khan and the franchise eye\u003C\u002Ffigcaption>\u003C\u002Ffigure>\n\u003Cp>\u003Cem>Source: The Print\u003C\u002Fem>\u003C\u002Fp>\n\u003Cp>Picture this.\u003C\u002Fp>\n\u003Cp>It’s a weekday evening somewhere in India. In a living room in Patna, a grandmother sits with her grandchildren watching two grown adults shriek at each other over a piece of fruit. In a Mumbai apartment, a group of college friends has gathered to watch a man gaslight his closest ally in the house — and then cheer when he does it cleverly enough. In a small town in Tamil Nadu, a teenager is watching a woman cry on camera, her face three inches from the lens, wondering whether this is what relationships look like.\u003C\u002Fp>\n\u003Cp>All of them are watching the same franchise. All of them are being told, in the quiet language of what gets replayed and rewarded, that this is entertainment.\u003C\u002Fp>\n\u003Cp>Bigg Boss launched in India in 2006. It is now 2026. In those twenty years, the show has run 19 Hindi seasons, expanded into seven regional languages — Tamil, Telugu, Kannada, Marathi, Malayalam, Bengali — spawned OTT editions, spin-offs, and celebrity specials. It has generated 43.8 billion viewing minutes. One season alone received 540 crore votes from the Indian public. The franchise reaches, by some estimates, close to 500 million people.\u003C\u002Fp>\n\u003Cp>Five hundred million.\u003C\u002Fp>\n\u003Cp>That is more than the population of the United States and Canada combined. That is one in every three Indians.\u003C\u002Fp>\n\u003Cp>And every single one of them has been watching people fight.\u003C\u002Fp>\n\u003Cp>We need to talk about what that’s done to us.\u003C\u002Fp>\n\u003Ch2>How the Machine Works\u003C\u002Fh2>\n\u003Cp>Bigg Boss doesn’t select housemates for their charm or talent. It selects them for their incompatibility — the person whose politics will clash with another’s, the ex-couple forced back into proximity, the volatile personality who will combust when provoked. The casting is a recipe, and the ingredient it is optimised for is explosive human drama.\u003C\u002Fp>\n\u003Cp>Then comes the architecture of the house itself. Tasks are not designed to test skill. They are designed to create situations in which people must compete against each other for resources — food, power, comfort, safety.\u003C\u002Fp>\n\u003Cp>Strip away comfort. Create scarcity. Add cameras. Watch what happens.\u003C\u002Fp>\n\u003Cp>When things settle down, the producers intervene. A Wild Card entry arrives, specifically chosen to disrupt existing alliances. The host asks pointed questions during Weekend Ka Vaar that reignite conflicts viewers thought were resolved. A task gets introduced that puts the two people currently in the most tension directly against each other.\u003C\u002Fp>\n\u003Cp>This is not coincidence. It is production design.\u003C\u002Fp>\n\u003Cp>And the people who were inside the house have confirmed it:\u003C\u002Fp>\n\u003Cul>\u003Cli>Rubina Dilaik, who won Bigg Boss 14, admitted that being the “channel’s favourite” helps and suggested the show involves scripting\u003C\u002Fli>\u003Cli>Hina Khan, a Bigg Boss 11 finalist, publicly called the Season 19 nomination process “fixed” and lacking in transparency\u003C\u002Fli>\u003Cli>Avinash Mishra from Bigg Boss 18 accused the production of providing “scripted protection” to select contestants through manipulated narratives\u003C\u002Fli>\u003Cli>In December 2024, contestant Eisha Singh was captured on camera appearing to read from a script during a segment\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>The producers deny all of it. They point to Ernst & Young audits of finale votes to prove integrity.\u003C\u002Fp>\n\u003Cp>But here is what is unambiguously true, regardless of whether any specific drama was scripted: the format is engineered for conflict. The incentives reward conflict. The people who get screen time, who go viral, who become household names — they are the people who fight loudest and cry hardest. The boring, stable, kind contestants leave early or are forgotten entirely.\u003C\u002Fp>\n\u003Cp>The machine rewards what it wants more of. And what it wants more of is aggression.\u003C\u002Fp>\n\u003Ch2>The Number That Should Disturb You\u003C\u002Fh2>\n\u003Cp>Researchers who study media content have counted the acts of aggression in reality television. Their finding:\u003C\u002Fp>\n\u003Cp>Reality TV shows contain \u003Cstrong>52 acts of aggression per hour\u003C\u002Fstrong>. Regular non-reality programs contain \u003Cstrong>33\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>That is 57% more aggression per hour than standard television.\u003C\u002Fp>\n\u003Cp>And not physical aggression — the kind that comes with consequences in the real world and is obviously coded as wrong. The aggression on Bigg Boss is overwhelmingly verbal and relational. Shouting. Insults. Emotional manipulation. Deliberate sabotage of friendships. Public humiliation. Backstabbing disguised as gameplay.\u003C\u002Fp>\n\u003Cp>This is the precise kind of aggression that is hardest for viewers to process correctly, because it isn’t clearly labeled as violence. It happens in the context of normal-looking human relationships. It comes from people whose names we know, whose histories we’ve followed, whose tears we’ve watched.\u003C\u002Fp>\n\u003Cp>Psychologists call this kind of normalized aggression a form of social learning. We learn what is acceptable — and what is effective — by watching other people. When we repeatedly see aggressive behavior go unpunished, or worse, get rewarded with screen time, votes, and fame, our brains quietly update their models of how the social world works.\u003C\u002Fp>\n\u003Cp>Multiple peer-reviewed studies have documented what follows:\u003C\u002Fp>\n\u003Cul>\u003Cli>Viewers who watch high-aggression reality TV are more likely to exhibit aggressive behaviors themselves\u003C\u002Fli>\u003Cli>Younger viewers who perceive reality TV as realistic are more likely to see social aggression as normal and even strategic\u003C\u002Fli>\u003Cli>Female viewers of docu-soap reality programming showed stronger normative beliefs about aggression after watching\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Bigg Boss runs three to four episodes per week, across a three-month season, in seven languages.\u003C\u002Fp>\n\u003Cp>We are not watching a show. We are attending a school.\u003C\u002Fp>\n\u003Ch2>What It Does to the People Inside\u003C\u002Fh2>\n\u003Cp>Before we get to what Bigg Boss does to its viewers, we should account for what it does to its contestants.\u003C\u002Fp>\n\u003Cp>Actor Apurva Agnihotri, who participated in the show, did not mince words: contestants end up taking “psychiatric help” after the show’s conclusion. He said this plainly in an interview — not as a rumour, but as a reported fact.\u003C\u002Fp>\n\u003Cp>Consider the environment. You are cut off from family, friends, and all outside information for months. You live with strangers who are competing against you. You are filmed twenty-four hours a day. You know that your most vulnerable moments — your arguments, your breakdowns, your worst words — are being broadcast to tens of millions of people and discussed in real time on social media.\u003C\u002Fp>\n\u003Cp>And when you leave, you return to a world that has been watching and judging you for three months.\u003C\u002Fp>\n\u003Cp>Bigg Boss 19 illustrated this with unusual clarity:\u003C\u002Fp>\n\u003Cul>\u003Cli>Contestant Farrhana Bhatt’s family took legal action against another contestant’s relative, seeking ₹1 crore in damages for “reputational and emotional harm”\u003C\u002Fli>\u003Cli>A contestant’s ex-wife began posting Instagram stories about his behavior in the house, dragging the entire extended personal network of real people into manufactured entertainment\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>These are real people. Their reputations, their relationships, their mental health — all of it fed into the entertainment engine, processed, and served to half a billion viewers.\u003C\u002Fp>\n\u003Cp>The format treats human beings as raw material.\u003C\u002Fp>\n\u003Ch2>The Women Problem\u003C\u002Fh2>\n\u003Cp>This section needs to be written directly, without euphemism.\u003C\u002Fp>\n\u003Cp>If you have watched Bigg Boss across multiple seasons, you have watched this pattern repeat: a female contestant is shouted at by a male contestant, at length, often inches from her face. The footage is replayed. It goes viral. People online debate whether she “provoked” it. At the Weekend Ka Vaar, the host scolds the aggressor — gently, briefly — before moving on to the entertaining content of the week.\u003C\u002Fp>\n\u003Cp>The aggressive male contestant remains in the house. He is called “strong” and “passionate.”\u003C\u002Fp>\n\u003Cp>The female contestant who responded, or cried, or fought back? She is called “dramatic” or “attention-seeking.”\u003C\u002Fp>\n\u003Cp>Research on reality TV and gender has documented exactly this asymmetry. A 2018 study found that female viewers of reality programming showed increased acceptance of sexualized aggression — including coercive tactics — through a mechanism of gender role normalization. When women repeatedly watch media in which male aggression toward women is depicted without serious consequence, it shifts their baseline expectations of what is normal.\u003C\u002Fp>\n\u003Cp>Millions of young Indian women watch Bigg Boss. They watch men shout and stay. They watch women who react get criticized. They watch Salman Khan — one of the most powerful men in Indian entertainment — navigate these moments with practiced lightness, making sure nobody is too uncomfortable, making sure we can all tune in again tomorrow.\u003C\u002Fp>\n\u003Cp>When the most powerful man in the room treats aggression as manageable background noise, viewers internalize that too.\u003C\u002Fp>\n\u003Ch2>The Economy of Outrage\u003C\u002Fh2>\n\u003Cp>Here is the thing about Bigg Boss that its critics often miss: the show doesn’t need you to like it. It needs you to have opinions about it.\u003C\u002Fp>\n\u003Cp>The business model has evolved far beyond television ratings. Today, Bigg Boss generates revenue through:\u003C\u002Fp>\n\u003Cul>\u003Cli>Votes people pay to cast\u003C\u002Fli>\u003Cli>Branded tasks that are advertisements in disguise\u003C\u002Fli>\u003Cli>OTT subscriptions driven by exclusive content\u003C\u002Fli>\u003Cli>The social media conversation that runs parallel to the broadcast\u003C\u002Fli>\u003Cli>The influencer ecosystem it creates around former contestants\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>None of this requires you to enjoy what you’re watching. Outrage drives engagement just as effectively as admiration. The person tweeting “I can’t believe what [contestant] just said” is serving the machine just as loyally as the fan posting appreciation.\u003C\u002Fp>\n\u003Cp>Controversy is not a side effect of Bigg Boss. It is the point.\u003C\u002Fp>\n\u003Cp>This is why the show consistently casts contestants with pre-existing controversies, unresolved relationship drama, or documented volatile behavior. Not despite the potential for explosions — because of it.\u003C\u002Fp>\n\u003Cp>There is now an entire media ecosystem that lives off Bigg Boss — YouTube channels dedicated to daily recaps, Instagram pages that track every alliance shift, Reddit threads dissecting every conversation, Twitter trends that spike with every fight. Most of this content is produced and consumed by people who would tell you, if you asked, that the show is stupid and toxic.\u003C\u002Fp>\n\u003Cp>But they’re watching.\u003C\u002Fp>\n\u003Cp>Bigg Boss OTT on JioCinema broke digital viewership records with over 10 crore viewers for one season. The franchise has grown every year it has existed, absorbing criticism, surviving controversy, expanding into new languages and new platforms — because the engine works and there is no shortage of fuel.\u003C\u002Fp>\n\u003Cp>We are the fuel.\u003C\u002Fp>\n\u003Ch2>The Aspiration It Sells\u003C\u002Fh2>\n\u003Cp>Twenty years ago, a young person from a small Indian city who dreamed of being famous had limited options. They could pursue acting through the conventional struggle. They could try sports. They could hope to be discovered somehow, somewhere.\u003C\u002Fp>\n\u003Cp>Today, that same young person watches Bigg Boss and understands that there is a faster path.\u003C\u002Fp>\n\u003Cp>You don’t need training. You don’t need talent. You need to be willing to live your worst moments on national television, to fight in public, to make enemies, to cry on demand, and to survive long enough for people to vote for you.\u003C\u002Fp>\n\u003Cp>This is now a viable career path.\u003C\u002Fp>\n\u003Cp>The formula is legible to anyone paying attention:\u003C\u002Fp>\n\u003Cul>\u003Cli>Don’t be boring, because boring people get eliminated\u003C\u002Fli>\u003Cli>Create conflict, because conflict creates screen time\u003C\u002Fli>\u003Cli>If you have pre-existing personal drama, bring it inside the house — the producers will reward you with visibility\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>We have built a system that selects for these qualities, rewards them with money and fame, and broadcasts the results to 500 million people. And we are surprised when critics worry about what it is teaching the next generation about what success looks like.\u003C\u002Fp>\n\u003Cp>The aspiration it sells is not: be talented, work hard, develop something worth admiring.\u003C\u002Fp>\n\u003Cp>The aspiration it sells is: be willing to make a spectacle of yourself, and the country will reward you for it.\u003C\u002Fp>\n\u003Ch2>The Deeper Question\u003C\u002Fh2>\n\u003Cp>I want to be careful here, because the easy conclusion — “Bigg Boss is bad, stop watching it” — misses something important.\u003C\u002Fp>\n\u003Cp>Bigg Boss didn’t invent the human appetite for watching conflict. That appetite is ancient. Roman gladiatorial games. Public executions. The stocks in the town square. The tendency to gather and watch when something violent or humiliating is happening is not a creation of Indian television in 2006. It is a feature of human psychology that has been there for as long as we have records.\u003C\u002Fp>\n\u003Cp>What Bigg Boss did was industrialize it.\u003C\u002Fp>\n\u003Cp>It took that appetite and built a year-round machine that produces conflict on demand, distributes it at scale, monetizes every second of engagement, and optimizes the product based on which conflicts generate the most attention. It removed the friction and the shame from consuming this content by making it mainstream — making it Salman Khan’s domain, making it something you watch with your family on a weeknight.\u003C\u002Fp>\n\u003Cp>The question isn’t whether you’re a bad person for watching Bigg Boss. Most people aren’t.\u003C\u002Fp>\n\u003Cp>The question is whether we’ve thought clearly about what we’re participating in when we do.\u003C\u002Fp>\n\u003Cp>When we vote, we are funding the next season. When we discuss the contestants online, we are extending the show’s reach. When we watch because we’re angry at what happened, we are proving to the producers that anger works as a retention mechanism. When we introduce the show to our children as harmless family entertainment, we are making the first of many decisions about what they will absorb as normal.\u003C\u002Fp>\n\u003Cp>Researchers who study media effects make an important distinction: a single exposure rarely changes behavior meaningfully. What changes behavior is repeated, normalized exposure over time. One episode of Bigg Boss is not going to rewire anyone’s brain. But twenty years of seasons — across seven languages, reaching half a billion people — is a different calculation entirely.\u003C\u002Fp>\n\u003Ch2>What We’re Really Choosing\u003C\u002Fh2>\n\u003Cp>India is not short of things to watch.\u003C\u002Fp>\n\u003Cp>We have a filmmaking tradition that produced \u003Cem>Mughal-E-Azam\u003C\u002Fem>, \u003Cem>Sholay\u003C\u002Fem>, \u003Cem>Lagaan\u003C\u002Fem>, and \u003Cem>Gully Boy\u003C\u002Fem>. We have documentary filmmakers doing extraordinary work. We have regional cinema in Malayalam, Tamil, and Marathi that has been recognized internationally as among the best being made anywhere. We have web series that take complex characters seriously.\u003C\u002Fp>\n\u003Cp>We also have Bigg Boss — which has run for 20 seasons and counting, because the market responds to what we choose, and we have chosen this reliably, repeatedly, across the entire country, in every language, across every platform, for two decades.\u003C\u002Fp>\n\u003Cp>The show will continue as long as we participate. That’s not a moral argument. It’s just how markets work.\u003C\u002Fp>\n\u003Cp>What I’m asking is smaller than a boycott.\u003C\u002Fp>\n\u003Cp>I’m asking whether we’ve been honest with ourselves about what we’re actually getting from it. The thing we tell ourselves — that we’re just having fun, that it’s harmless, that we don’t take it seriously — doesn’t quite hold up when you look at the numbers. You don’t give 540 crore votes to something you’re casually dismissing.\u003C\u002Fp>\n\u003Cp>We’re invested. Deeply.\u003C\u002Fp>\n\u003Cp>That investment has costs that mostly don’t show up in the moment you’re casting a vote or watching the highlight clip. They show up slowly — in what we consider normal, in how we expect conflict to unfold, in what we think fame should look like, in what we believe powerful people owe the people they hurt.\u003C\u002Fp>\n\u003Cp>The show has been teaching us for twenty years.\u003C\u002Fp>\n\u003Cp>The question — the only question worth asking — is whether we’ve been good students.\u003C\u002Fp>\n\u003Cp>I write about Indian culture, building things, and the parts of growth nobody talks about. Find me on \u003Ca href=\"https:\u002F\u002Fx.com\u002Fjainprayush9\" target=\"_blank\" rel=\"noopener noreferrer\">X\u003C\u002Fa> and \u003Ca href=\"https:\u002F\u002Fyoutube.com\u002F@jainprayush9\" target=\"_blank\" rel=\"noopener noreferrer\">YouTube\u003C\u002Fa>.\u003C\u002Fp>",{"slug":306,"title":307,"excerpt":308,"topic":309,"platform":266,"url":310,"xUrl":269,"substackUrl":269,"date":311,"dateLabel":312,"year":272,"readTime":273,"cover":313,"content":314,"full":276},"everything-you-need-to-know-about-the-nse-ipo-before-you-apply","Everything You Need to Know About the NSE IPO Before You Apply","Everyone has an opinion on the NSE IPO. Your broker says subscribe. Your WhatsApp group says it’s overpriced. The grey market says 12%… Continue reading on Medium »","investing","https:\u002F\u002Fjainprayush9.medium.com\u002Feverything-you-need-to-know-about-the-nse-ipo-before-you-apply-a2796edad62e","2026-09-17T14:24:22.000Z","Sep 17, 2026","\u002Fimages\u002Fessays\u002Fnse-ipo\u002Fcover.jpg","\u003Cfigure class=\"essay-figure\">\u003Cimg src=\"\u002Fimages\u002Fessays\u002Fnse-ipo\u002Fcover.jpg\" alt=\"NSE IPO — Everything you need to know before you apply\" loading=\"lazy\" \u002F>\u003Cfigcaption>NSE IPO — Everything you need to know before you apply\u003C\u002Ffigcaption>\u003C\u002Ffigure>\n\u003Cp>Everyone has an opinion on the NSE IPO. Your broker says subscribe. Your WhatsApp group says it’s overpriced. The grey market says 12% listing gains. Your uncle says it’s the safest bet in years.\u003C\u002Fp>\n\u003Cp>None of them have read the numbers.\u003C\u002Fp>\n\u003Cp>This is not a hype piece. The NSE IPO is genuinely one of the most interesting listings India has seen in a long time. But interesting and worth investing in are two different things. Here’s the full picture so you can decide for yourself.\u003C\u002Fp>\n\u003Ch2>What Is This IPO, Actually?\u003C\u002Fh2>\n\u003Cp>The National Stock Exchange of India is going public. The same exchange where you’ve been buying and selling stocks for years is now offering you a chance to own a piece of it.\u003C\u002Fp>\n\u003Cp>The IPO opens on \u003Cstrong>September 17\u003C\u002Fstrong> and closes on \u003Cstrong>September 21, 2026\u003C\u002Fstrong>. Shares are expected to list on BSE on \u003Cstrong>September 24, 2026\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>The quick facts:\u003C\u002Fp>\n\u003Cul>\u003Cli>\u003Cstrong>Price band:\u003C\u002Fstrong> Rs 1,700 to Rs 1,785 per share\u003C\u002Fli>\u003Cli>\u003Cstrong>Lot size:\u003C\u002Fstrong> 8 shares\u003C\u002Fli>\u003Cli>\u003Cstrong>Minimum investment:\u003C\u002Fstrong> Rs 14,280 (at upper band)\u003C\u002Fli>\u003Cli>\u003Cstrong>Issue size:\u003C\u002Fstrong> Approximately Rs 21,500 to Rs 22,500 crore\u003C\u002Fli>\u003Cli>\u003Cstrong>IPO type:\u003C\u002Fstrong> 100% Offer for Sale (OFS)\u003C\u002Fli>\u003Cli>\u003Cstrong>Listing exchange:\u003C\u002Fstrong> BSE\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>That last point deserves its own section.\u003C\u002Fp>\n\u003Ch2>The OFS Problem (Read This Before Anything Else)\u003C\u002Fh2>\n\u003Cp>This is a 100% Offer for Sale. Every single rupee you invest goes to the existing shareholders who are selling their stake. Not one rupee goes to NSE as a company.\u003C\u002Fp>\n\u003Cp>That is not automatically a red flag. Many great companies have done OFS IPOs. But it does mean:\u003C\u002Fp>\n\u003Cul>\u003Cli>NSE isn’t raising money to grow, build, or expand\u003C\u002Fli>\u003Cli>The people who built it are cashing out\u003C\u002Fli>\u003Cli>You’re buying someone else’s exit, not funding someone’s vision\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>When you see a 100% OFS, the first question to ask is: why are insiders choosing to sell now? Sometimes the answer is that the business is mature and they simply want liquidity. Sometimes the answer is that the valuation is about as good as it’s going to get for a while.\u003C\u002Fp>\n\u003Cp>With NSE, both are probably true.\u003C\u002Fp>\n\u003Ch2>The Business: Genuinely Exceptional\u003C\u002Fh2>\n\u003Cp>Set the OFS concern aside for a moment. The underlying business is remarkable.\u003C\u002Fp>\n\u003Cp>NSE controls \u003Cstrong>92.99%\u003C\u002Fstrong> of India’s cash equity market. In derivatives, the dominance is even more extreme. The registered investor base grew from \u003Cstrong>30.87 million\u003C\u002Fstrong> in March 2020 to \u003Cstrong>129 million\u003C\u002Fstrong> in March 2026. That’s 4x growth in six years.\u003C\u002Fp>\n\u003Cp>The financials tell the same story:\u003C\u002Fp>\n\u003Cul>\u003Cli>\u003Cstrong>Net profit margin (FY26):\u003C\u002Fstrong> 55%\u003C\u002Fli>\u003Cli>\u003Cstrong>EBITDA margin (FY26):\u003C\u002Fstrong> 75.48%\u003C\u002Fli>\u003Cli>\u003Cstrong>Debt:\u003C\u002Fstrong> Zero\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>A 75% operating margin. No debt. A near-monopoly on India’s trading infrastructure. For long-term investors, this is the kind of business that compounds quietly for decades. The question is never whether NSE is a good business. It clearly is. The question is what price you’re paying for it.\u003C\u002Fp>\n\u003Ch2>The Numbers That Worry Me\u003C\u002Fh2>\n\u003Cp>Here’s what the hype pieces aren’t telling you.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>FY26 revenue fell.\u003C\u002Fstrong> NSE’s revenue from operations came in at Rs 16,601 crore in FY26, down 3.1% from Rs 17,140 crore in FY25.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>FY26 profit fell harder.\u003C\u002Fstrong> Profit after tax dropped to Rs 10,302 crore, down 15.5% from Rs 12,188 crore the previous year.\u003C\u002Fp>\n\u003Cp>This is not a company growing into its valuation. This is a company being listed in the year its earnings declined. The reason is SEBI’s F&O (Futures and Options) curbs, which squeezed derivatives volumes significantly. NSE’s entire business model runs on transaction fees. Fewer derivatives trades means less revenue, less profit.\u003C\u002Fp>\n\u003Cp>The risk is not that NSE is a bad business. The risk is that its single biggest revenue driver, the derivatives segment, is now directly in SEBI’s crosshairs. SEBI changed the rules once. They can change them again.\u003C\u002Fp>\n\u003Ch2>Valuation: Cheaper Than BSE, Expensive vs the World\u003C\u002Fh2>\n\u003Cp>At the upper price band of Rs 1,785, NSE is priced at:\u003C\u002Fp>\n\u003Cul>\u003Cli>\u003Cstrong>42.89x\u003C\u002Fstrong> FY26 earnings (P\u002FE)\u003C\u002Fli>\u003Cli>\u003Cstrong>13.76x\u003C\u002Fstrong> FY26 book value\u003C\u002Fli>\u003Cli>\u003Cstrong>26.61x\u003C\u002Fstrong> FY26 revenue\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>For context, BSE currently trades at \u003Cstrong>54.28x\u003C\u002Fstrong> earnings. So NSE is cheaper than BSE on a PE basis, despite being roughly 3.4x BSE’s revenue and 4x its profit. On a relative basis, NSE looks like the better value of the two.\u003C\u002Fp>\n\u003Cp>But compare it to global exchanges and the picture changes. NASDAQ trades at a fraction of its listed market cap. Euronext even lower. NSE is being valued at roughly 1.2–1.3% of the market cap of stocks listed on it. Global peers average well below 0.2%.\u003C\u002Fp>\n\u003Cp>The counter-argument is that India is a growth market and NSE deserves a premium. That argument isn’t wrong. But “deserves a premium” and “this specific premium at this specific moment, with falling profits” are different things.\u003C\u002Fp>\n\u003Ch2>The Regulatory Risk Is Real and Specific\u003C\u002Fh2>\n\u003Cp>NSE isn’t just exposed to generic market risk. It has a specific, documented history with regulators.\u003C\u002Fp>\n\u003Cp>The co-location scandal, where certain brokers allegedly got preferential access to trading servers for years, resulted in penalties and prolonged scrutiny. The IPO itself was delayed for years partly due to regulatory concerns stemming from that episode.\u003C\u002Fp>\n\u003Cp>SEBI approved the IPO. But the co-location case isn’t fully closed in public memory. And the F&O curbs that already hurt FY26 profits show that SEBI is comfortable intervening in NSE’s core revenue model when it deems necessary.\u003C\u002Fp>\n\u003Cp>Regulatory risk with NSE isn’t theoretical. It’s already showing up in the income statement.\u003C\u002Fp>\n\u003Ch2>Grey Market Premium: What It Means and What It Doesn’t\u003C\u002Fh2>\n\u003Cp>The GMP (Grey Market Premium) is currently sitting around \u003Cstrong>Rs 218 to Rs 222\u003C\u002Fstrong> per share, suggesting a potential listing premium of roughly \u003Cstrong>12%\u003C\u002Fstrong> over the upper price band.\u003C\u002Fp>\n\u003Cp>A few things to understand about GMP:\u003C\u002Fp>\n\u003Cul>\u003Cli>It’s an unofficial market. There’s no regulation, no enforcement, no guarantee.\u003C\u002Fli>\u003Cli>GMP reflects short-term listing sentiment, not long-term value.\u003C\u002Fli>\u003Cli>It can change dramatically in the days between now and listing, especially if market conditions shift.\u003C\u002Fli>\u003Cli>Listing gains and long-term returns are completely different conversations.\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>If the GMP holds, someone applying at the upper band of Rs 1,785 might see the stock list around Rs 2,000. That’s a decent short-term return on a retail lot. But past big IPOs have seen GMP evaporate by listing day when broader markets got volatile.\u003C\u002Fp>\n\u003Cp>Don’t apply to NSE IPO because of GMP. Apply or don’t apply based on your actual view of the business.\u003C\u002Fp>\n\u003Ch2>How to Apply (If You Decide To)\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Via UPI\u003C\u002Fstrong> (easiest for retail investors):\u003C\u002Fp>\n\u003Col>\u003Cli>Open your broker app (Zerodha, Groww, Upstox, Angel, etc.)\u003C\u002Fli>\u003Cli>Go to IPO section and find NSE IPO\u003C\u002Fli>\u003Cli>Enter lot size and bid price (bid at Rs 1,785 to maximise allotment chances)\u003C\u002Fli>\u003Cli>Enter your UPI ID\u003C\u002Fli>\u003Cli>Approve the mandate on your UPI app within the deadline\u003C\u002Fli>\u003C\u002Fol>\n\u003Cp>\u003Cstrong>Via ASBA\u003C\u002Fstrong> (through your bank):\u003C\u002Fp>\n\u003Col>\u003Cli>Log in to your bank’s net banking\u003C\u002Fli>\u003Cli>Go to the IPO\u002FASBA section\u003C\u002Fli>\u003Cli>Enter your demat account details, lot size, and price\u003C\u002Fli>\u003Cli>Submit; the amount is blocked, not debited, until allotment\u003C\u002Fli>\u003C\u002Fol>\n\u003Cp>\u003Cstrong>Important:\u003C\u002Fstrong> Apply only once across all platforms. Multiple applications using the same PAN are rejected. If oversubscribed (almost certain), retail allotment is by lottery — one lot per lucky applicant.\u003C\u002Fp>\n\u003Ch2>So Should You Apply?\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Apply if:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\u003Cli>You want long-term exposure to India’s capital markets growth story\u003C\u002Fli>\u003Cli>You’re comfortable holding through potential post-listing volatility\u003C\u002Fli>\u003Cli>You see this as a 5–10 year hold, not a quick flip\u003C\u002Fli>\u003Cli>You understand that a near-monopoly exchange in a country growing its investor base 4x per decade is a structurally sound bet\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Think twice if:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\u003Cli>You’re hoping for guaranteed listing gains. The GMP suggests upside but nothing is guaranteed with a Rs 22,000 crore issue.\u003C\u002Fli>\u003Cli>You’re worried about valuation. At 43x declining earnings, this is not a cheap stock.\u003C\u002Fli>\u003Cli>You’re uncomfortable with regulatory risk. SEBI has intervened in NSE’s revenue model before and can do so again.\u003C\u002Fli>\u003Cli>You’re expecting the same 54x re-rating as BSE. Whether that premium expands from here is genuinely uncertain.\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>NSE is a great business at a fair-to-full price, being sold partly because profits just dropped 15%. The long-term bull case is India’s investor growth story. The short-term risk is that the IPO is coming at peak valuation during a year of declining earnings.\u003C\u002Fp>\n\u003Ch2>The One Thing Most People Are Missing\u003C\u002Fh2>\n\u003Cp>Everyone is debating whether NSE deserves a higher PE than BSE. That’s the wrong conversation.\u003C\u002Fp>\n\u003Cp>The right question is this: what happens to NSE’s earnings if SEBI continues tightening F&O regulations?\u003C\u002Fp>\n\u003Cp>Derivatives are NSE’s crown jewel. They’re also increasingly under regulatory scrutiny, with SEBI citing retail investor losses in options trading as a concern. If that scrutiny deepens and volumes fall further, FY26’s 15.5% profit decline won’t be an anomaly. It’ll be the beginning of a trend.\u003C\u002Fp>\n\u003Cp>NSE’s monopoly position doesn’t protect it from that risk. If SEBI decides that options trading needs to be curtailed for retail investor protection, NSE can’t simply pivot to another revenue stream overnight.\u003C\u002Fp>\n\u003Cp>That’s not a reason to never invest. It’s a reason to size your position with that risk in mind.\u003C\u002Fp>\n\u003Cp>The business is exceptional. The timing is imperfect. The price is fair but not cheap.\u003C\u002Fp>\n\u003Cp>Apply with clear eyes, not because everyone else is.\u003C\u002Fp>\n\u003Cblockquote>\u003Cp>This is not financial advice. Do your own research and consult a registered financial advisor before making investment decisions.\u003C\u002Fp>\u003C\u002Fblockquote>",{"slug":306,"title":316,"excerpt":317,"topic":309,"platform":266,"url":310,"xUrl":269,"substackUrl":269,"date":318,"dateLabel":319,"year":272,"readTime":273,"cover":313,"content":314,"full":276},"Everything You Need to Know About X Monetisation","Most people aren’t confused about X monetisation. They’re scared of looking late. Continue reading on ILLUMINATION »","2026-09-11T05:01:34.000Z","Sep 11, 2026",{"slug":321,"title":322,"excerpt":323,"topic":14,"platform":266,"url":324,"xUrl":325,"substackUrl":326,"date":327,"dateLabel":328,"year":272,"readTime":329,"cover":330,"content":331,"full":276},"shame-is-the-tax-you-pay-for-staying-small","Shame Is the Tax You Pay for Staying Small","Most people never build anything, not because they lack ideas or time, but because somewhere along the way they decided that looking foolish was worse than staying invisible. That decision quietly puts a ceiling on your…","https:\u002F\u002Fjainprayush9.medium.com\u002Fshame-is-the-tax-you-pay-for-staying-small-ae1701e9fc4e","https:\u002F\u002Fx.com\u002Fjainprayush9\u002Fstatus\u002F2087982767221223863","https:\u002F\u002Fjainprayush9.substack.com\u002Fp\u002Fshame-is-the-tax-you-pay-for-staying","2026-08-13T19:32:42.000Z","Aug 13, 2026","3 min","\u002Fimages\u002Fessays\u002Fshame-tax\u002Fcover.jpg","\u003Cfigure class=\"essay-figure\">\u003Cimg src=\"\u002Fimages\u002Fessays\u002Fshame-tax\u002Fcover.jpg\" alt=\"Shame is the tax you pay for staying small\" loading=\"lazy\" \u002F>\u003Cfigcaption>Shame is the tax you pay for staying small\u003C\u002Ffigcaption>\u003C\u002Ffigure>\n\u003Cp>Most people never build anything, not because they lack ideas or time, but because somewhere along the way they decided that looking foolish was worse than staying invisible. That decision quietly puts a ceiling on your life.\u003C\u002Fp>\n\u003Cp>Think about everything you've wanted to try but didn't: posting your first video, writing online, starting a business, learning to code, building a product, sharing an opinion that isn't perfectly formed yet. The fear underneath usually isn't failure. It's being seen failing. You can get something wrong in private. The moment other people can watch you struggle, the stakes feel enormous; i.e, friends might laugh, colleagues might think you're trying too hard, family might wonder why you're doing something so different. So you don't do it. Nobody laughs. It feels like a win.\u003C\u002Fp>\n\u003Cp>Until a few years pass and you realize you protected yourself from embarrassment at the cost of becoming someone you never wanted to be.\u003C\u002Fp>\n\u003Cp>This is why being shameless matters. Not arrogant or careless, but willing to look stupid while you're still learning. Almost everything worth getting good at requires a stretch where you're bad at it. Your first videos will be awkward, your first writing mediocre, your first product might completely fail. That's not a warning sign. That's what the beginning looks like.\u003C\u002Fp>\n\u003Cp>The mistake is believing you need to become good before you let yourself be seen. You don't. You become good by letting yourself be seen while you're still bad, and this is where being young helps more than people admit. You have room to experiment, change your mind, start something unrelated to what you studied, embarrass yourself, and recover with time to spare.\u003C\u002Fp>\n\u003Cp>So try everything. Especially the things you're slightly embarrassed to try. Write the blog even if your English isn't perfect. Build the product even if you don't fully know what you're doing. Post the video even if you hate the sound of your own voice. You don't need to know in advance which one will work. You're collecting reps, and every rep teaches you something: what people respond to, what you're actually good at, what you enjoy enough to keep doing when nobody's watching yet.\u003C\u002Fp>\n\u003Cp>Even the failures pay you back. The video that gets twenty views teaches you something. The product nobody buys teaches you something. The article nobody reads teaches you something. None of that is wasted effort; it's tuition for skills that eventually compound.\u003C\u002Fp>\n\u003Cp>There's a second trap that keeps people small: treating the opinions around you like facts. Your friends might not understand what you're building. Your family might push you toward something safer. That doesn't mean you're wrong; it might just mean you're doing something they wouldn't do. You don't have to shrink your ambitions until they're comfortable for everyone around you. You don't need everyone to believe in you. You need enough conviction to keep going when they don't.\u003C\u002Fp>\n\u003Cp>And the honest part: this might not work. The video might flop. The blog might get four views. The product might quietly die in three months. The idea you've been obsessing over might turn out to be terrible. That's fine. The goal was never to make every attempt succeed. The goal is to become someone who can keep attempting because eventually something does work. One post reaches the right person. One idea gets shared. One product finds its first real customer. You can't manufacture that moment, but you can multiply the chances you give yourself to find it. Luck finds the people willing to be seen trying.\u003C\u002Fp>\n\u003Cp>So stop optimizing your life around avoiding embarrassment. There's no version of your future where everyone understands you, approves of you, and you still do something remarkable. At some point you choose: spend your years looking competent, or spend them becoming competent. The second path is more uncomfortable, and it's where almost everything worth having actually happens.\u003C\u002Fp>\n\u003Cp>Post the cringe video. Write the imperfect article. Build the ugly product. Learn the skill you're terrible at. Let people laugh.\u003C\u002Fp>\n\u003Cp>Shame is not the price of failure. It's the tax you pay for refusing to stay small.\u003C\u002Fp>\n\u003Cp>Pay it. Then keep going.\u003C\u002Fp>",{"slug":321,"title":322,"excerpt":333,"topic":334,"platform":266,"url":324,"xUrl":325,"substackUrl":326,"date":335,"dateLabel":328,"year":272,"readTime":329,"cover":330,"content":331,"full":276},"Most people never build anything, not because they lack ideas or time, but because somewhere along the way they decided that looking… Continue reading on Medium »","career","2026-08-13T19:19:41.000Z",{"slug":337,"title":338,"excerpt":339,"topic":265,"platform":266,"url":340,"xUrl":269,"substackUrl":269,"date":341,"dateLabel":342,"year":272,"readTime":343,"cover":269,"content":344,"full":276},"shipping-got-easy-keeping-systems-honest-got-hard","Shipping Got Easy — Keeping Systems Honest Got Hard","A few years ago, the bottleneck on most engineering teams was obvious: building the thing. Continue reading on JavaScript in Plain English »","https:\u002F\u002Fjavascript.plainenglish.io\u002Fshipping-got-easy-keeping-systems-honest-got-hard-baed53ff04ca","2026-07-28T19:52:26.000Z","Jul 28, 2026","9 min","\u003Cp>A few years ago, the bottleneck on most engineering teams was obvious: building the thing.\u003C\u002Fp>\n\u003Cp>That is less true now. Frameworks, platforms, templates, and AI coding tools made it dramatically cheaper to stand up a feature, a service, a dashboard, or an alert rule. You can go from idea to merged PR faster than most organizations can schedule a design review.\u003C\u002Fp>\n\u003Cp>So the constraint moved. The hard part is no longer “can we ship this?” The hard part is “who keeps this true after we ship it?”\u003C\u002Fp>\n\u003Cfigure class=\"essay-figure\">\u003Cimg src=\"\u002Fimages\u002Fessays\u002Fshipping-got-easy\u002Fhero.jpg\" alt=\"The constraint moved from shipping to ownership\" loading=\"lazy\" \u002F>\u003Cfigcaption>The constraint moved from shipping to ownership\u003C\u002Ffigcaption>\u003C\u002Ffigure>\n\u003Cp>If you own a service, an on-call rotation, or the dashboards people open at 2 a.m., this is for you.\u003C\u002Fp>\n\u003Cp>Call it the \u003Cstrong>creation-to-ownership gap\u003C\u002Fstrong>: the widening distance between how easy it is to create something and how little capacity anyone budgets to keep it honest afterward.\u003C\u002Fp>\n\u003Cp>It shows up everywhere creation got cheap, and ownership stayed optional:\u003C\u002Fp>\n\u003Cul>\u003Cli>Feature flags that ship in an afternoon and linger for years\u003C\u002Fli>\u003Cli>Dashboards built during an incident and abandoned afterward\u003C\u002Fli>\u003Cli>Dependencies added in one PR and audited never, until a CVE forces the conversation\u003C\u002Fli>\u003Cli>Alerts added “just in case,” then muted forever\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Alerting is the sharpest case study, because bad signal does not just waste time. It trains people to stop listening.\u003C\u002Fp>\n\u003Ch2>Why alerts stop meaning anything\u003C\u002Fh2>\n\u003Cp>Every engineering team eventually builds the same thing without meaning to: a monitoring setup that pages people constantly and helps nobody.\u003C\u002Fp>\n\u003Cp>It does not happen on purpose. It happens one well-intentioned alert at a time. A threshold after an incident. A Slack notification “just in case.” A dashboard metric promoted to a page. Each addition feels responsible in isolation. Together, they train your own engineers to stop trusting the alarm.\u003C\u002Fp>\n\u003Cp>That is the real failure mode. Not that alerting is too quiet. That it is too loud, too often, about things that do not matter, until the one time it is loud about something that does, and nobody is listening anymore.\u003C\u002Fp>\n\u003Ch2>The fable everyone knows and nobody applies\u003C\u002Fh2>\n\u003Cp>The boy who cried wolf is not a story about lying. It is a story about \u003Cstrong>signal decay\u003C\u002Fstrong>. Every false alarm does not just fail to help. It actively degrades the value of every future alarm. By the time the real wolf shows up, the villagers have already learned, correctly, that responding costs more than it is worth.\u003C\u002Fp>\n\u003Cp>Most alerting systems run exactly this experiment on their own engineers, every week, without noticing.\u003C\u002Fp>\n\u003Ch2>The two costs nobody puts on a dashboard\u003C\u002Fh2>\n\u003Ch3>1. The direct cost — on-call burnout\u003C\u002Fh3>\n\u003Cp>An engineer who gets paged four times a night, three of which turn out to be nothing, does not sleep less on paper. They sleep less in practice, because the anxiety of an unpredictable pager is its own tax, independent of whether anything was actually wrong. Teams do not usually connect rising attrition or declining on-call morale to alert volume, but it is one of the most direct lines between infrastructure decisions and people decisions in engineering.\u003C\u002Fp>\n\u003Ch3>2. The invisible cost — trust decay\u003C\u002Fh3>\n\u003Cp>This is the more expensive one, and it compounds silently. Once an engineer learns that a specific alert is “usually nothing,” they stop treating it as an event that requires full attention. They glance, dismiss, move on. This is a rational adaptation to a noisy environment. Still, it means that when that same alert fires because something is actually wrong, the response time is identical to when it was nothing. The alert has not failed technically. It has failed as communication, which is all an alert ever really is.\u003C\u002Fp>\n\u003Ch2>Why this gets worse as systems grow\u003C\u002Fh2>\n\u003Cp>A five-service system can afford a slightly noisy alerting setup because a human can hold the whole picture in their head. That stops being true almost immediately as systems scale:\u003C\u002Fp>\n\u003Cul>\u003Cli>More services means more places for thresholds to be set without coordination\u003C\u002Fli>\u003Cli>More integrations mean more third-party status changes get treated as “alerts” by default\u003C\u002Fli>\u003Cli>More dashboards mean more temptation to wire every visible metric to a notification\u003C\u002Fli>\u003Cli>More on-call rotations mean less institutional memory about why a given alert exists at all\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Nobody sits down and designs a bad alerting system. It accretes, one reasonable-sounding addition at a time, with no equivalent process for subtraction. Nobody’s job is to remove alerts. Everybody’s job, implicitly, is to add them.\u003C\u002Fp>\n\u003Cp>That is the creation-to-ownership gap in miniature. Creation is easy. Subtraction has no owner.\u003C\u002Fp>\n\u003Cp>AI coding tools widen it further. They make it even easier to scaffold another service, another monitor, another “temporary” flag, without anyone adding matching capacity to maintain what just got created. Speed of generation is not the same as capacity to own.\u003C\u002Fp>\n\u003Cp>There is a second trap that looks sophisticated: the \u003Cstrong>passive monitoring trap\u003C\u002Fstrong>. Teams build beautiful dashboards, then assume someone is watching. Nobody is watching on a reliable schedule. Dashboards are opt-in. Pages are interruptive. If critical change only exists on a panel, you have reporting, not response.\u003C\u002Fp>\n\u003Chr \u002F>\n\u003Ch2>What to do instead\u003C\u002Fh2>\n\u003Cp>This is where most “how to set up Grafana\u002FLast9” posts stop at screenshots. The missing half is design that survives a real on-call rotation.\u003C\u002Fp>\n\u003Ch3>The only alert filter that matters\u003C\u002Fh3>\n\u003Cp>Not every signal deserves to interrupt a human.\u003C\u002Fp>\n\u003Cblockquote>\u003Cp>An alert should exist only if a human needs to take a specific action right now, and that action is not already automated.\u003C\u002Fp>\u003C\u002Fblockquote>\n\u003Cp>Run every candidate alert through that test:\u003C\u002Fp>\n\u003Cul>\u003Cli>Informational state changes belong on a dashboard, not a page\u003C\u002Fli>\u003Cli>Scripted responses should be automated, not routed to a person\u003C\u002Fli>\u003Cli>“Useful context” belongs in a log or thread, not a notification\u003C\u002Fli>\u003Cli>Duplicate symptoms of one failure should be one alert, not five\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>The test is not “is this true and worth knowing.” Almost everything is. The test is whether someone must act now, urgently enough to interrupt whatever they were doing.\u003C\u002Fp>\n\u003Cp>If you only take one practical rule from this article, take that filter.\u003C\u002Fp>\n\u003Ch3>Make the alert itself actionable\u003C\u002Fh3>\n\u003Cp>A good alert is a work order, not a riddle. When it fires, the person receiving it should not need to reverse-engineer your intentions at 2 a.m.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Bad:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cpre>\u003Ccode>ALERT: cpu_usage_percent{service=checkout} > 80 for 5m\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Cstrong>Better:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cpre>\u003Ccode>Checkout p95 latency is above SLO (currently 1.8s, budget burn high).\nUsers are seeing slow payments.\nOpen the Checkout first-five-minutes dashboard → Latency panel.\nRunbook: https:\u002F\u002F...\u002Fcheckout-latency.\nIf not recovering in 10 minutes, page Payments on-call.\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Every page-worthy alert should include:\u003C\u002Fp>\n\u003Cul>\u003Cli>What broke in plain language (not only a metric name)\u003C\u002Fli>\u003Cli>Why it matters (user impact, SLO risk, blast radius)\u003C\u002Fli>\u003Cli>Where to look first (link to the right dashboard panel, not the homepage)\u003C\u002Fli>\u003Cli>What to do next (runbook \u002F SOP steps)\u003C\u002Fli>\u003Cli>Who else to involve if mitigation stalls (escalation)\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>If your tool supports advanced fields (investigation guide, false-positive notes, severity, references), fill them. Empty rule metadata is how “create alert” becomes creation without ownership.\u003C\u002Fp>\n\u003Cp>Also prefer smarter thresholds where you can. Static lines like CPU > 80 are easy to ship and easy to cry wolf. Prefer symptoms users feel (error rate, latency, freshness, availability) and thresholds tied to history or SLO burn when possible. Threshold alerts, anomaly-style alerts, and trend-change alerts all have a place. Vanity metrics do not.\u003C\u002Fp>\n\u003Ch3>Route to people who can act\u003C\u002Fh3>\n\u003Cp>Alert fatigue is often a routing problem disguised as a volume problem.\u003C\u002Fp>\n\u003Cul>\u003Cli>Send pages only to people empowered to act\u003C\u002Fli>\u003Cli>Keep FYI \u002F deploy \u002F minor blips out of the must-act channel\u003C\u002Fli>\u003Cli>Prefer team-owned routes over “everyone engineering”\u003C\u002Fli>\u003Cli>Deduplicate and thread: one incident, one conversation, updates instead of five identical pings\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Slack made alerting feel cheap. A noisy Slack channel is still a trust failure. It is just quieter about it. Separate must-act from awareness. Thread instead of repeating. Attach the runbook every time.\u003C\u002Fp>\n\u003Ch3>Build a “first five minutes” dashboard, not a museum\u003C\u002Fh3>\n\u003Cp>Dashboards and alerts get treated as interchangeable, and they are not.\u003C\u002Fp>\n\u003Cul>\u003Cli>\u003Cstrong>Dashboards\u003C\u002Fstrong> answer: how are we doing, on a human schedule?\u003C\u002Fli>\u003Cli>\u003Cstrong>Alerts\u003C\u002Fstrong> answer: does someone need to act right now?\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>A useful service dashboard for on-call usually covers a small, opinionated set of views. Steal this shape even if your tool is Grafana, Kibana, Datadog, or something else:\u003C\u002Fp>\n\u003Cul>\u003Cli>Variables people can change without editing the dashboard (env, service, percentile, time resolution)\u003C\u002Fli>\u003Cli>SLOs \u002F user symptoms (availability, latency, error rate)\u003C\u002Fli>\u003Cli>Server \u002F API view (traffic, errors, hot endpoints)\u003C\u002Fli>\u003Cli>Async\u002Fbackground work if you have queues or cron\u003C\u002Fli>\u003Cli>Client view when you have client-side telemetry\u003C\u002Fli>\u003Cli>System resources (CPU, memory, runtime-specific stats)\u003C\u002Fli>\u003Cli>Dependency health (the thing that usually breaks you at 3 a.m.)\u003C\u002Fli>\u003Cli>Alerts section with only the graphs that actually page, plus links to SOPs\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Two rules that keep dashboards honest:\u003C\u002Fp>\n\u003Col>\u003Cli>Do not wire every panel into an alert. Pick essential graphs only.\u003C\u002Fli>\u003Cli>Alert configuration should not depend on casual dashboard variables. Alerts need fixed evaluation windows and explicit thresholds.\u003C\u002Fli>\u003C\u002Fol>\n\u003Cp>If a panel does not help in the first five minutes of an incident, it probably does not belong on the primary on-call view. Put archaeology elsewhere.\u003C\u002Fp>\n\u003Ch3>Connect alert → investigation → incident → learning\u003C\u002Fh3>\n\u003Cp>Mature setups do one more thing tutorials often skip: close the loop.\u003C\u002Fp>\n\u003Cp>When a real alert fires, the path should be obvious:\u003C\u002Fp>\n\u003Col>\u003Cli>Alert fires with context and runbook\u003C\u002Fli>\u003Cli>On-call lands on the first-five-minutes dashboard\u003C\u002Fli>\u003Cli>If it is a real incident, declare\u002Fopen an incident channel\u003C\u002Fli>\u003Cli>Capture timeline and owners\u003C\u002Fli>\u003Cli>Afterward, look at detection and response quality (MTTD, MTTR, noisy rules, missing signals)\u003C\u002Fli>\u003C\u002Fol>\n\u003Cp>If alerts never produce learning, the creation-to-ownership gap reopens. You will keep adding rules and never retire the ones that trained people to mute the channel.\u003C\u002Fp>\n\u003Ch2>What to do this week\u003C\u002Fh2>\n\u003Cp>Most teams do not need a new alerting platform. They need an audit.\u003C\u002Fp>\n\u003Cp>For each noisy alert, ask: when this last fired, did a human take a specific action because of it? If the answer is usually no, that is not a tooling problem. It is an unmaintained list of things somebody once thought were important.\u003C\u002Fp>\n\u003Cp>Buying another tool before this audit usually just moves the noise somewhere more expensive.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Practical pass:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Col>\u003Cli>List your top 20 noisiest alerts by fire count\u003C\u002Fli>\u003Cli>For each, check the last three fires: what action was taken?\u003C\u002Fli>\u003Cli>Delete, demote to dashboard-only, or fix the ones with no action\u003C\u002Fli>\u003Cli>Rewrite survivors so they include impact, dashboard link, and runbook\u003C\u002Fli>\u003Cli>Rebuild one service dashboard around the first-five-minutes template above\u003C\u002Fli>\u003Cli>Put a name next to alert + dashboard hygiene for that service for the next quarter\u003C\u002Fli>\u003C\u002Fol>\n\u003Cp>That is more valuable than another panel.\u003C\u002Fp>\n\u003Ch2>This is not only about alerts\u003C\u002Fh2>\n\u003Cp>Alerting is the sharpest example of the creation-to-ownership gap, not the only one. The same pattern shows up in flags nobody removes, dashboards nobody owns, and dependencies nobody audits until something breaks. AI tools accelerate creation without budgeting ownership. If your organization only celebrates shipping, you will keep optimizing the easy side of the ledger.\u003C\u002Fp>\n\u003Cp>The teams that age well treat ownership as first-class work: code, alerts, dashboards, flags, dependencies, runbooks. Not as cleanup for when the roadmap has spare room, because it never does.\u003C\u002Fp>\n\u003Ch2>The real question\u003C\u002Fh2>\n\u003Cp>Every team believes their alerting system tells the truth until they actually check. The uncomfortable audit is not “do we have enough monitoring.” Almost everyone has plenty. It is “when this last fired, did anyone actually do anything about it, or did they just make it stop.”\u003C\u002Fp>\n\u003Cp>If the honest answer is the second one more often than the first, the alerting system is not protecting anyone. It is just training your best engineers to stop listening.\u003C\u002Fp>\n\u003Cp>And the broader question behind that one is the title of this piece: now that shipping is easy, who is responsible for keeping what you shipped honest?\u003C\u002Fp>\n\u003Cblockquote>\u003Cp>How much of your alert volume right now would survive the test: did a human take a specific action because of this?\u003C\u002Fp>\u003C\u002Fblockquote>",{"slug":346,"title":347,"excerpt":348,"topic":265,"platform":266,"url":349,"xUrl":269,"substackUrl":269,"date":350,"dateLabel":351,"year":272,"readTime":293,"cover":269,"content":352,"full":276},"the-hidden-tax-every-engineering-team-is-paying-and-doesnt-talk-about","The Hidden Tax Every Engineering Team Is Paying (And Doesn’t Talk About)","There’s a number almost no engineering org tracks: how many collective hours their developers spend staring at a build progress bar every… Continue reading on JavaScript in Plain English »","https:\u002F\u002Fjavascript.plainenglish.io\u002Fthe-hidden-tax-every-engineering-team-is-paying-and-doesnt-talk-about-f58fce33d365","2026-07-27T18:27:21.000Z","Jul 27, 2026","\u003Cp>There’s a number almost no engineering org tracks: how many collective hours their developers spend staring at a build progress bar every week.\u003C\u002Fp>\n\u003Cp>Not writing code. Not designing systems. Not shipping features. Just… waiting.\u003C\u002Fp>\n\u003Cp>If your team runs 30–40 builds a day, and each one takes 50 minutes instead of 15, you’re not losing 35 minutes. You’re losing 35 minutes multiplied by every engineer, every build, every day, compounding into months of lost engineering time a year. And unlike a production outage, nobody files an incident report for a slow build. It just quietly taxes your velocity forever, until someone decides to fix it.\u003C\u002Fp>\n\u003Cp>Build optimization doesn’t get the attention it deserves because it doesn’t look like a “real” engineering problem. It’s not a new feature. It’s not a scaling milestone. It’s plumbing. But plumbing determines how fast everything else in the house works.\u003C\u002Fp>\n\u003Cfigure class=\"essay-figure\">\u003Cimg src=\"\u002Fimages\u002Fessays\u002Fhidden-tax\u002Fci-cd-loop.jpg\" alt=\"CI\u002FCD is a loop — every slow stage compounds forever\" loading=\"lazy\" \u002F>\u003Cfigcaption>CI\u002FCD is a loop — every slow stage compounds forever\u003C\u002Ffigcaption>\u003C\u002Ffigure>\n\u003Ch2>The Two Costs Nobody Puts on a Slide\u003C\u002Fh2>\n\u003Cfigure class=\"essay-figure\">\u003Cimg src=\"\u002Fimages\u002Fessays\u002Fhidden-tax\u002Fcompute.png\" alt=\"Compute is the visible bill — context switching is the invisible one\" loading=\"lazy\" \u002F>\u003Cfigcaption>Compute is the visible bill — context switching is the invisible one\u003C\u002Ffigcaption>\u003C\u002Ffigure>\n\u003Ch3>1. The direct cost — compute\u003C\u002Fh3>\n\u003Cp>Every build consumes CPU, memory, and often paid CI minutes. A bloated pipeline running redundant steps, rebuilding unchanged modules, or spinning up oversized runners is literally burning money on infrastructure that produces nothing. At scale (hundreds of builds a day across a growing team), this adds up to a real, visible line item. Companies routinely discover they’re paying for 3–4x more compute than the actual work requires, simply because nobody audited the pipeline since it was first written.\u003C\u002Fp>\n\u003Ch3>2. The invisible cost — context switching\u003C\u002Fh3>\n\u003Cp>This one is more expensive, and almost nobody measures it. When a build takes 40–50+ minutes, developers don’t sit and watch it. They switch tasks, check Slack, open a different ticket, and then pay a “resumption tax” when they come back to reload the mental model of what they were doing. Research on developer flow state consistently shows that switching costs far exceed the wait time itself. A 50-minute build isn’t a 50-minute cost. It’s often far more once you account for how long it takes to get back into deep focus, and how many times that interruption happens in a day.\u003C\u002Fp>\n\u003Cp>Multiply that across a team, across a year, and slow builds become one of the largest hidden drains on engineering productivity, bigger than most teams’ entire “developer experience” budget.\u003C\u002Fp>\n\u003Ch2>Why This Gets Worse as You Scale, Not Better\u003C\u002Fh2>\n\u003Cp>Early on, builds are fast because codebases are small. Nobody notices the problem until it’s already expensive to fix. As a codebase grows:\u003C\u002Fp>\n\u003Cul>\u003Cli>Dependency graphs get tangled, and clean modularization erodes\u003C\u002Fli>\u003Cli>More tests get added without a parallelization strategy\u003C\u002Fli>\u003Cli>CI pipelines accumulate steps nobody remembers the purpose of\u003C\u002Fli>\u003Cli>Caching layers are either missing or invalidated too aggressively to help\u003C\u002Fli>\u003Cli>Generated artifacts creep into version control and become everyone’s problem\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>In a monorepo, this compounds faster. One slow path isn’t one team’s problem. It’s every team’s wait time, every PR, every day. A redundant step in a shared pipeline taxes backend, frontend, and platform engineers alike. A bad cache key or an unbalanced test shard shows up as “CI is slow” for the whole org, not one squad.\u003C\u002Fp>\n\u003Cfigure class=\"essay-figure\">\u003Cimg src=\"\u002Fimages\u002Fessays\u002Fhidden-tax\u002Fmonorepo.jpg\" alt=\"One shared pipeline — every team pays the same tax\" loading=\"lazy\" \u002F>\u003Cfigcaption>One shared pipeline — every team pays the same tax\u003C\u002Ffigcaption>\u003C\u002Ffigure>\n\u003Cp>The result is a slow, creeping decline that’s easy to rationalize away one sprint at a time (“it’s just a bit slower this quarter”) until a team wakes up to 40–50 minute builds and wonders how they got there.\u003C\u002Fp>\n\u003Cp>There’s a related trap that looks like progress: throwing more machines at it. Parallelization helps. But parallelizing work you shouldn’t be doing at all has a cost curve that goes the wrong way. You can finish earlier and spend more.\u003C\u002Fp>\n\u003Ch2>What Actually Moves the Needle\u003C\u002Fh2>\n\u003Cp>Not all optimizations are equal. A small set of principles accounts for most of the gains:\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Only rebuild what changed.\u003C\u002Fstrong> Incremental builds sound obvious, but a shocking number of pipelines still rebuild the world on every commit because incremental support was never configured, or was configured once and quietly broken.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Cache for correctness first, speed second.\u003C\u002Fstrong> Shared caching is where real gains show up. The hard part isn’t turning a cache on. It’s versioning it so it doesn’t lie across branches, toolchains, or parallel writers.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Parallelize the right work, then balance it.\u003C\u002Fstrong> A tangled “everything depends on everything” graph makes parallelization impossible no matter what tooling you buy. And even when you fan out, unbalanced shards leave agents idle while the slowest one owns wall-clock. “Parallel” is not the same as “balanced.”\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Delete ceremony. Decouple prove from ship.\u003C\u002Fstrong> The same lint or type-check often runs in the PR gate and again in the deploy build. Unit tests rarely need a full production packaging step. If your feedback loop waits on work that isn’t required for that job’s purpose, you’re paying a coupling tax.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Stop treating humans as a build step.\u003C\u002Fstrong> Unused dependencies, oversized artifacts, and committed generated output silently slow builds, reviews, and merges. Hygiene is unglamorous and pays for itself repeatedly.\u003C\u002Fp>\n\u003Cp>None of this is exotic. The reason it doesn’t get fixed isn’t lack of solutions. It’s lack of ownership. Build performance sits in the gap between “not really infra’s job” and “not really product engineering’s job,” so it drifts.\u003C\u002Fp>\n\u003Ch2>How to Actually Achieve It\u003C\u002Fh2>\n\u003Cp>Knowing the principles isn’t enough. Order matters, especially in a monorepo where “fix the build” can feel too big to start.\u003C\u002Fp>\n\u003Ch3>1. Instrument before you optimize\u003C\u002Fh3>\n\u003Cp>Break the pipeline into stages and measure wall-clock: dependency restore, compile\u002Fpackage, lint, unit tests (per shard), integration\u002Fe2e, artifact publish. Find the slowest stage and the widest gap between shards. Those two numbers tell you where to go first.\u003C\u002Fp>\n\u003Ch3>2. Draw the dependency graph of the pipeline\u003C\u002Fh3>\n\u003Cp>For every job, ask: does this step need to succeed for this job’s purpose? PR gates need correctness signals. Deploy builds need shippable artifacts. Local loops need the shortest path to “is my change broken?” Anything that appears twice without a reason is a deletion candidate.\u003C\u002Fp>\n\u003Ch3>3. Delete before you parallelize\u003C\u002Fh3>\n\u003Cp>This is the sequence that consistently pays off:\u003C\u002Fp>\n\u003Col>\u003Cli>Remove duplicate gates\u003C\u002Fli>\u003Cli>Decouple test from ship\u003C\u002Fli>\u003Cli>Stop committing generated artifacts\u003C\u002Fli>\u003Cli>Fix cache correctness (version by branch\u002Flockfile\u002Ftoolchain; isolate parallel writers)\u003C\u002Fli>\u003Cli>Replace the slow tool on the hot path\u003C\u002Fli>\u003Cli>Parallelize the bottleneck itself (a single-threaded step on a 16-core box is not fixed by more CI agents)\u003C\u002Fli>\u003Cli>Rebalance shards (idle agents are still cost)\u003C\u002Fli>\u003Cli>Only then buy more machines\u003C\u002Fli>\u003C\u002Fol>\n\u003Cp>If you reverse this order, you often get a faster and more expensive pipeline.\u003C\u002Fp>\n\u003Ch3>4. Ship it as a portfolio, not a hero PR\u003C\u002Fh3>\n\u003Cp>One dramatic change rarely delivers a lasting win. A sequence of small, measured improvements does. Track before\u002Fafter per stage so the org doesn’t forget and reintroduce the fat.\u003C\u002Fp>\n\u003Ch3>5. Assign an owner\u003C\u002Fh3>\n\u003Cp>Someone has to be accountable for pipeline wall-clock and CI cost the way someone owns latency SLOs. Without that, every sprint prefers a product ticket over plumbing, and the tax keeps compounding.\u003C\u002Fp>\n\u003Ch2>How I Did It in a Monorepo\u003C\u002Fh2>\n\u003Cp>I own this story from inside a large production monorepo: many modules, shared libraries, multiple CI paths, and a build that had grown the way monorepo builds usually do, by accretion.\u003C\u002Fp>\n\u003Cp>The starting point looked familiar. Packaging paths that redid far more work than they needed to. A custom asset-processing step that didn’t scale with available cores. Caches that existed but weren’t versioned or isolated safely for parallel workers. Quality checks running twice, once as a PR gate and again in the deploy path. Unit tests gated behind a full production-style build they didn’t need. Test shards that were “parallel” but uneven. Generated artifacts committed to git (on the order of ~150K+ lines), creating noisy diffs, merge conflicts, and a manual rebuild ritual.\u003C\u002Fp>\n\u003Cp>None of that is unique to one language or framework. It’s what happens when a monorepo’s shared pipeline is everyone’s infrastructure and nobody’s roadmap item.\u003C\u002Fp>\n\u003Cp>I worked the sequence above. Made the bottleneck itself parallel instead of only fanning the same slow step across more agents. Cached correctly, not just “on,” with branch-based versioning and per-worker cache directories. Deleted duplicate static analysis and decoupled unit tests from the ship build. Rebalanced uneven test shards so agents finished closer together. Moved generated artifacts into the pipeline and out of git. Replaced a CPU-heavy step on the hot path with a much faster tool. Cleaned the long tail: unused dependencies, LTS upgrades, better dependency caching, sensible test timeouts.\u003C\u002Fp>\n\u003Cp>What didn’t work was also useful. A popular “rewrite the compiler stack for speed” migration looked great on paper but failed the risk\u002Freward test under our framework constraints. Documenting why a trendy optimization doesn’t apply saves the next engineer weeks.\u003C\u002Fp>\n\u003Cp>Results on the paths I owned:\u003C\u002Fp>\n\u003Cul>\u003Cli>~10–15 minutes faster on the first major build path\u003C\u002Fli>\u003Cli>~19–20 minutes faster on the second\u003C\u002Fli>\u003Cli>~32 minutes of wall-clock saved combined\u003C\u002Fli>\u003Cli>~50% cost reduction on those builds, because we removed work, not only parallelized it\u003C\u002Fli>\u003Cli>~150K+ LOC of generated artifacts out of version control\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>The monorepo lesson that stuck with me: optimizations in a shared pipeline are force multipliers. One deleted step, one correct cache, one balanced shard, and every team that ships through that pipeline inherits the win. That’s also why ownership matters more here than in a single-service repo. If nobody owns the shared path, everybody pays.\u003C\u002Fp>\n\u003Ch2>The Business Case, Not Just the Engineering Case\u003C\u002Fh2>\n\u003Cp>If you’re trying to get this prioritized, don’t pitch it as a developer comfort issue. Pitch it as what it actually is: a cost and velocity issue.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Cost:\u003C\u002Fstrong> Reduced CI compute time translates directly into lower cloud spend, often the single easiest infrastructure cost to cut with zero product risk.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Velocity:\u003C\u002Fstrong> Faster feedback loops mean faster iteration, faster bug fixes, and faster time-to-production, which compounds across every team that ships through that pipeline.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Retention:\u003C\u002Fstrong> Developer experience is a real retention lever. Engineers notice when their tools work against them, and “our build is painfully slow” is a recurring theme in exit interviews at companies that never invested here.\u003C\u002Fp>\n\u003Cp>Framed this way, build optimization stops looking like a nice-to-have cleanup task and starts looking like what it is: one of the highest-leverage, lowest-risk investments an engineering org can make. You’re not betting on an unproven feature. You’re removing friction from something every single engineer touches, every single day.\u003C\u002Fp>\n\u003Ch2>The Real Question\u003C\u002Fh2>\n\u003Cp>The question isn’t whether your build pipeline has room to improve. Almost every pipeline does, because nobody budgets time to maintain it the way they budget time to build features. The real question is whether anyone owns it.\u003C\u002Fp>\n\u003Cp>If the honest answer is “not really,” that’s usually the actual problem worth solving first, especially in a monorepo, where the tax is shared, and the ownership gap is largest.\u003C\u002Fp>\n\u003Cp>What’s the slowest part of your build pipeline right now, and has anyone actually looked at why?\u003C\u002Fp>",{"slug":354,"title":355,"excerpt":356,"topic":14,"platform":357,"url":358,"xUrl":269,"substackUrl":269,"date":359,"dateLabel":360,"year":361,"readTime":362,"cover":363,"content":364,"full":276},"the-philosophy-of-cause-and-its-effect","The Philosophy of “Cause and its Effect”","We are all born into different time zones, environments, and upbringings, but there is one thing that we are all taught in common: the philosophy of good and bad. But we are never taught the philosophy of cause and effec…","Substack","https:\u002F\u002Fjainprayush9.substack.com\u002Fp\u002Fthe-philosophy-of-cause-and-its-effect","2025-10-03T13:04:58.000Z","Oct 3, 2025",2025,"1 min","https:\u002F\u002Fsubstackcdn.com\u002Fimage\u002Ffetch\u002F$s_!9zjc!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep\u002Fhttps%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fa4581f38-c823-48e1-8651-6e24f92a1545_960x960.jpeg","\u003Cdiv class=\"captioned-image-container\">\u003Cfigure>\u003Ca class=\"image-link image2 is-viewable-img\" target=\"_blank\" href=\"https:\u002F\u002Fsubstackcdn.com\u002Fimage\u002Ffetch\u002F$s_!Gy75!,f_auto,q_auto:good,fl_progressive:steep\u002Fhttps%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc7e40b9a-4983-4152-b172-b94425858658_256x320.jpeg\" data-component-name=\"Image2ToDOM\">\u003Cdiv class=\"image2-inset\">\u003Cpicture>\u003Csource type=\"image\u002Fwebp\" srcset=\"https:\u002F\u002Fsubstackcdn.com\u002Fimage\u002Ffetch\u002F$s_!Gy75!,w_424,c_limit,f_webp,q_auto:good,fl_progressive:steep\u002Fhttps%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc7e40b9a-4983-4152-b172-b94425858658_256x320.jpeg 424w, https:\u002F\u002Fsubstackcdn.com\u002Fimage\u002Ffetch\u002F$s_!Gy75!,w_848,c_limit,f_webp,q_auto:good,fl_progressive:steep\u002Fhttps%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc7e40b9a-4983-4152-b172-b94425858658_256x320.jpeg 848w, https:\u002F\u002Fsubstackcdn.com\u002Fimage\u002Ffetch\u002F$s_!Gy75!,w_1272,c_limit,f_webp,q_auto:good,fl_progressive:steep\u002Fhttps%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc7e40b9a-4983-4152-b172-b94425858658_256x320.jpeg 1272w, https:\u002F\u002Fsubstackcdn.com\u002Fimage\u002Ffetch\u002F$s_!Gy75!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep\u002Fhttps%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc7e40b9a-4983-4152-b172-b94425858658_256x320.jpeg 1456w\" sizes=\"100vw\">\u003Cimg src=\"https:\u002F\u002Fsubstackcdn.com\u002Fimage\u002Ffetch\u002F$s_!Gy75!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep\u002Fhttps%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc7e40b9a-4983-4152-b172-b94425858658_256x320.jpeg\" width=\"256\" height=\"320\" data-attrs=\"{"src":"https:\u002F\u002Fsubstack-post-media.s3.amazonaws.com\u002Fpublic\u002Fimages\u002Fc7e40b9a-4983-4152-b172-b94425858658_256x320.jpeg","srcNoWatermark":null,"fullscreen":null,"imageSize":null,"height":320,"width":256,"resizeWidth":null,"bytes":null,"alt":null,"title":null,"type":null,"href":null,"belowTheFold":false,"topImage":true,"internalRedirect":null,"isProcessing":false,"align":null,"offset":false}\" class=\"sizing-normal\" alt=\"\" srcset=\"https:\u002F\u002Fsubstackcdn.com\u002Fimage\u002Ffetch\u002F$s_!Gy75!,w_424,c_limit,f_auto,q_auto:good,fl_progressive:steep\u002Fhttps%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc7e40b9a-4983-4152-b172-b94425858658_256x320.jpeg 424w, https:\u002F\u002Fsubstackcdn.com\u002Fimage\u002Ffetch\u002F$s_!Gy75!,w_848,c_limit,f_auto,q_auto:good,fl_progressive:steep\u002Fhttps%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc7e40b9a-4983-4152-b172-b94425858658_256x320.jpeg 848w, https:\u002F\u002Fsubstackcdn.com\u002Fimage\u002Ffetch\u002F$s_!Gy75!,w_1272,c_limit,f_auto,q_auto:good,fl_progressive:steep\u002Fhttps%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc7e40b9a-4983-4152-b172-b94425858658_256x320.jpeg 1272w, https:\u002F\u002Fsubstackcdn.com\u002Fimage\u002Ffetch\u002F$s_!Gy75!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep\u002Fhttps%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc7e40b9a-4983-4152-b172-b94425858658_256x320.jpeg 1456w\" sizes=\"100vw\" fetchpriority=\"high\">\u003C\u002Fpicture>\u003Cdiv class=\"image-link-expand\">\u003Cdiv class=\"pencraft pc-display-flex pc-gap-8 pc-reset\">\u003Cbutton tabindex=\"0\" type=\"button\" class=\"pencraft pc-reset pencraft icon-container restack-image buttonBase-GK1x3M\">\u003Csvg aria-hidden=\"true\" width=\"20\" height=\"20\" viewBox=\"0 0 20 20\" fill=\"none\" stroke-width=\"1.5\" stroke=\"var(--color-fg-primary)\" stroke-linecap=\"round\" stroke-linejoin=\"round\" xmlns=\"http:\u002F\u002Fwww.w3.org\u002F2000\u002Fsvg\" class=\"icon-noB79L\">\u003Cg>\u003Cpath d=\"M2.53001 7.81595C3.49179 4.73911 6.43281 2.5 9.91173 2.5C13.1684 2.5 15.9537 4.46214 17.0852 7.23684L17.6179 8.67647M17.6179 8.67647L18.5002 4.26471M17.6179 8.67647L13.6473 6.91176M17.4995 12.1841C16.5378 15.2609 13.5967 17.5 10.1178 17.5C6.86118 17.5 4.07589 15.5379 2.94432 12.7632L2.41165 11.3235M2.41165 11.3235L1.5293 15.7353M2.41165 11.3235L6.38224 13.0882\">\u003C\u002Fpath>\u003C\u002Fg>\u003C\u002Fsvg>\u003C\u002Fbutton>\u003Cbutton tabindex=\"0\" type=\"button\" class=\"pencraft pc-reset pencraft icon-container view-image buttonBase-GK1x3M\">\u003Csvg xmlns=\"http:\u002F\u002Fwww.w3.org\u002F2000\u002Fsvg\" width=\"20\" height=\"20\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\" class=\"lucide lucide-maximize2 lucide-maximize-2 icon-noB79L\">\u003Cpolyline points=\"15 3 21 3 21 9\">\u003C\u002Fpolyline>\u003Cpolyline points=\"9 21 3 21 3 15\">\u003C\u002Fpolyline>\u003Cline x1=\"21\" x2=\"14\" y1=\"3\" y2=\"10\">\u003C\u002Fline>\u003Cline x1=\"3\" x2=\"10\" y1=\"21\" y2=\"14\">\u003C\u002Fline>\u003C\u002Fsvg>\u003C\u002Fbutton>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fa>\u003C\u002Ffigure>\u003C\u002Fdiv>\u003Cp>We are all born into different time zones, environments, and upbringings, but there is one thing that we are all taught in common: the philosophy of good and bad. But we are never taught the philosophy of cause and effect. What I feel is that all certainty in our relationships with the world rests on the acknowledgment of cause and its effect. Ours is a world of cause and its effect. Other phenomena cause every phenomenon and give rise to another phenomenon.\u003C\u002Fp>\u003Cp>Certain things happen in our lives, and we question ourselves that “Why does this happen to me? “But that specific cause is the sum-total of the circumstances whose interaction gave rise to that effect, and that will lead to another effect.\u003C\u002Fp>\u003Cp>What I feel good about the philosophy of good and bad is that when good deeds are done, they make us feel confident and empowered, and if something bad is done, it leads to regret about the thing. But the best part about the philosophy of cause and its effect is that we know we are the cause, and so have to bear its effect. That gives us the strength and power to face any problem and makes us feel confident.\u003C\u002Fp>\u003Ch3>\u003Cem>\u003Cstrong>“Shallow men believe in luck or in circumstances. Strong men believe in cause and its effect.” ~ Emerson\u003C\u002Fstrong>\u003C\u002Fem>\u003C\u002Fh3>\u003Cdiv>\u003Chr>\u003C\u002Fdiv>\u003Cp>\u003C\u002Fp>\u003Cdiv class=\"subscription-widget-wrap-editor\" data-attrs=\"{"url":"https:\u002F\u002Fjainprayush9.substack.com\u002Fsubscribe?","text":"Subscribe","language":"en"}\" data-component-name=\"SubscribeWidgetToDOM\">\u003Cdiv class=\"subscription-widget show-subscribe\">\u003Cdiv class=\"preamble\">\u003Cp class=\"cta-caption\">Thanks for reading Prayush’s Substack! Subscribe for free to receive new posts and support my work.\u003C\u002Fp>\u003C\u002Fdiv>\u003Cform class=\"subscription-widget-subscribe\">\u003Cinput type=\"email\" class=\"email-input\" name=\"email\" placeholder=\"Type your email…\" tabindex=\"-1\">\u003Cinput type=\"submit\" class=\"button primary\" value=\"Subscribe\">\u003Cdiv class=\"fake-input-wrapper\">\u003Cdiv class=\"fake-input\">\u003C\u002Fdiv>\u003Cdiv class=\"fake-button\">\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fform>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cp>Feel free to reach out and follow me on these social media platforms — \u003Ca href=\"https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fjainprayush9\u002F\">LinkedIn\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fwww.youtube.com\u002Fchannel\u002FUClTaK5iNKLPdY9uYMq5sTEg\">YouTube\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Ftwitter.com\u002Fjainprayush9\">Twitter\u003C\u002Fa>, and \u003Ca href=\"https:\u002F\u002Fwww.instagram.com\u002Fjainprayush9\">Instagram\u003C\u002Fa>.\u003C\u002Fp>",{"slug":366,"title":367,"excerpt":368,"topic":265,"platform":266,"url":369,"xUrl":269,"substackUrl":269,"date":370,"dateLabel":371,"year":361,"readTime":362,"cover":269,"content":372,"full":276},"realizations-you-have-after-5-years-of-coding","Realizations you have after 5+ years of coding","1\u002F Most problems are not technical. The code is usually the easy part. Miscommunication, unclear specs, and changing requirements cause… Continue reading on JavaScript in Plain English »","https:\u002F\u002Fjavascript.plainenglish.io\u002Frealizations-you-have-after-5-years-of-coding-6a3d69f5ff6d","2025-06-29T10:34:13.000Z","Jun 29, 2025","\u003Cfigure class=\"essay-figure\">\u003Cimg src=\"\u002Fimages\u002Fessays\u002Frealizations\u002Fthink-code.png\" alt=\"Think, then code\" loading=\"lazy\" \u002F>\u003Cfigcaption>Think, then code\u003C\u002Ffigcaption>\u003C\u002Ffigure>\n\u003Cp>\u003Cstrong>1\u002F Most problems are not technical.\u003C\u002Fstrong>   The code is usually the easy part. Miscommunication, unclear specs, and changing requirements cause most of the delays.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>2\u002F “It works” is not the same as “it’s done.”\u003C\u002Fstrong>   Working code isn’t always reliable, maintainable, or scalable. The second version is usually better.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>3\u002F Reading code is harder than writing it.\u003C\u002Fstrong>   Clean code isn’t just for others. It’s for your future self, who won’t remember why you did what you did.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>4\u002F You’ll never know everything.\u003C\u002Fstrong>   There’s always a new framework, language, or tool. Learning how to learn is more valuable than trying to master it all. Master the ability to learn, not just the tools themselves.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>5\u002F Tests are not optional.\u003C\u002Fstrong>   Good tests are like insurance. Even small projects benefit from tests. The time you save debugging later is worth the effort upfront.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>6\u002F Technical debt is not always bad.\u003C\u002Fstrong>   Sometimes you need to ship. The key is knowing which shortcuts are reversible and which aren’t.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>7\u002F Good code is simple code.\u003C\u002Fstrong>   Complex solutions often feel smart in the moment but become painful later. Simplicity wins long-term.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>8\u002F Collaboration beats heroism.\u003C\u002Fstrong>   The best engineers aren’t the ones who work alone all night. They’re the ones who elevate the team.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>9\u002F Imposter syndrome never fully goes away.\u003C\u002Fstrong>   Even experienced devs feel it. The difference is, you learn to work through it.\u003C\u002Fp>",{"slug":374,"title":375,"excerpt":376,"topic":334,"platform":266,"url":377,"xUrl":269,"substackUrl":269,"date":378,"dateLabel":379,"year":380,"readTime":273,"cover":269,"content":269,"full":381},"airtel-interview","Backend Engineer, Airtel: Interview Experience","An honest account of an interview that didn't end in an offer, and the things it taught me about hiring processes and communication.","https:\u002F\u002Fjainprayush9.medium.com\u002Fbackend-engineer-airtel-interview-experience-india-2022-e78a60af973c","2023-08-23T00:00:00.000Z","Aug 23, 2023",2023,false,{"slug":383,"title":384,"excerpt":385,"topic":334,"platform":266,"url":386,"xUrl":269,"substackUrl":269,"date":387,"dateLabel":388,"year":380,"readTime":293,"cover":269,"content":269,"full":381},"clevertap-internship","CleverTap Internship Experience","From final-year student at KIIT to shipping code at CleverTap: what the internship was actually like, and how it turned into a full-time role.","https:\u002F\u002Fjainprayush9.medium.com\u002Fclevertap-internship-experience-india-2022-1db96f8805d4","2023-08-12T00:00:00.000Z","Aug 12, 2023",1790063008571]