Reflection — An Honest Take 8 min

Honest Take — Before You Begin

Honest Take — Module 0: Why Engineers Resist Business Operations #

I want to start by naming what is probably already happening in your head. You opened this path, scrolled the outline, and felt a small specific kind of resistance — not the productive resistance of "this is hard," but the avoidant resistance of "this is boring and I have real work to do." That feeling is the diagnostic. It is not a sign the path is wrong. It is the symptom this module exists to treat. Most engineers I have ever known about, including the ones who later lost entities or got struck off the MCA register or paid 234C interest equal to a vacation, felt exactly that resistance and obeyed it. You inherited the resistance. You did not invent it. You are about to either obey it or examine it.

Here is the dishonest thing engineers tell themselves about ops, in four flavors. "My CA handles it" — your CA does not have a calendar invite to your life and does not know that you are about to onboard a US client without an LUT. "I'll deal with it when I have to" — every compliance failure I have read about ended this sentence with "and by then it was three penalties deep." "It's just paperwork" — paperwork that, when missing, freezes your bank account, which freezes your payroll, which freezes whatever mission you incorporated for. "The company is small, no one will notice" — the MCA's automated systems do not need to notice you personally. They notice the missing form. Each of these rationalizations is a specific cognitive move that lets you feel virtuous about avoidance. The framing "business ops is beneath the engineering work" is the most expensive flattery you could tell yourself, because the engineering work cannot exist without the entity that contains it.

Here is the truth the formal curriculum cannot say plainly: there is no glory in compliance. There is no Hacker News post for "filed GSTR-3B on time, twelve months running." No one will star your repo for renewing your DSC before it expired. The work is invisible when done well and catastrophic when not. That asymmetry is exactly why most engineers under-invest. But compare it to plumbing in a Rails app — there is no glory in database migrations either, and you don't ship a Rails app without them. The logging config does not get applause. Sentry alerts do not have a fan club. You do them anyway because you understand that production-grade work has unglamorous prerequisites. Your entity is now in production. Treat it that way.

Specifically about you — if you incorporated recently, the clock started the day the CIN was issued. You are not preparing to run an OPC. You are running one. There is a difference. The annual filings (AOC-4, MGT-7A) are due roughly Sep-Oct each year. Your first ITR has a date. Advance tax has four windows — Jun 15, Sep 15, Dec 15, Mar 15 — and the next one is closer than you think. None of these are theoretical. They have dates. You either know the dates or you are about to learn them under penalty.

There is one more thing I want to say honestly, because the rest of this path is not the place for it. If you incorporated because you want the entity to fund work that matters to you — over decades, not quarters — and if a family's financial future intersects with whether the entity survives, then none of that mission funds itself. The OPC is the vehicle that will hold the IP, the cash, the contracts, and the reputation that funds those goals over thirty years. A struck-off OPC funds nothing. A frozen account funds nothing. The compliance work in this path is not in tension with the mission; it is the protective layer around it. I am not going to be sentimental about this — the calendar entries are still calendar entries. But the reason to make them is not duty. It is preservation.

I want to address one specific defense I expect you to deploy as you read the rest of this path: "this is what I pay my CA for." The defense is partially correct and mostly insufficient. Your CA files forms. Your CA does not run your business. Your CA does not know on Tuesday morning that you are about to onboard a US client without an LUT. Your CA does not know that you forgot to deduct TDS on the payment you sent your designer last week. Your CA reconstructs at year-end based on what you bring to them. The quality of the year-end work is bounded by the quality of the year-long inputs you fed it. Founders who think their CA "handles it" are usually generating the inputs poorly and getting brittle outputs. Founders who treat their CA as a partner — a person they brief monthly with clean books — get outputs that hold up. The distinction is whether you treat the CA relationship as outsourcing (cheap and brittle) or as partnership (slightly more work and substantially more reliable). This path exists to make you the second kind of client.

A small thing about the Indian context that the curriculum cannot say but I can. Indian small-business compliance is heavier than US small-business compliance — more forms, more thresholds, more departments. This is not a failure of the Indian system; it is a feature of a regulated economy that runs on documented trails. You can either resent this fact every month for the rest of your entity's life (some founders do — the resentment becomes its own tax) or accept the tax of operating in this regulatory environment as a known cost and route around it efficiently. The acceptance saves more energy than any clever workaround. The founders I have read about who run Indian OPCs cleanly for a decade have all made some version of this peace. Make it early.

Conclusion #

This module is the git blame of your relationship to ops. The point is not to feel bad about your first months of incorporation without a runbook. The point is to identify the specific rationalizations that have already started running so the rest of the path has something concrete to refactor. If you finish this module without naming at least three rationalizations you have already used about your entity in the last month, you didn't go deep enough. The discomfort is the deliverable.

Predictions #

  • You will start the "What Could Kill My Studio in 24 Months" essay, write four bullets, and want to stop because the bullets feel paranoid. They are not paranoid. They are specific. Push past the four into ten.
  • The act of opening the recurring "Monthly Compliance Review" calendar entry will take you 90 seconds and produce more value than the next 8 hours of reading. Open it before you finish this module, not after.
  • You will resist this path more than Communication and more than Sales & Marketing, because those have visible outputs (essays, pitches) and this one's outputs are mostly absences (no notice, no penalty, no struck-off). Notice the resistance and proceed anyway.
  • Within two weeks you will catch yourself thinking "my CA handles it" about something specific. That micro-noticing is the first measurable sign the module is working. Write down the specific thing and look it up.
  • You will finish Module 0 in under 8 hours, faster than estimated, because most of the reading rewards skim plus reflection. Don't pad it. Move to Module 1.
  • Six months from now, when something almost goes wrong (a deadline you almost missed, a form you almost forgot), you will trace the save back to the calendar entry you opened in Module 0. That is when this module pays for itself.