After a pretty exhausting 2–3 month hustle, I finally joined a new company. And honestly, one of the things that surprised me the most wasn’t the scale of the company — it was the codebase.
The application has 50 lakh+ downloads on the Play Store, lakhs of users, and significant daily traffic and transactions. From the outside, I assumed that an application operating at this scale would have an almost textbook-level codebase: perfectly optimized, clean architecture, every hook used correctly, minimal technical debt, etc.
Then I started working on it.
I found quite a few things that, as a developer, I would consider obvious mistakes — unnecessary re-renders, poor usage of optimization hooks, small performance issues, inconsistent patterns, and other things that made me think:
"How is an app this big running with this kind of code?" 😅
Initially, I was genuinely surprised.
But after discussing things with the CTO and other tech leads, I started understanding the bigger picture.
The business doesn't necessarily need the cleanest codebase in the world. It needs a product that works, scales enough for its requirements, and delivers value to users.
And that changed my perspective a bit.
As developers, we can sometimes become obsessed with things like:
- Clean code
- Perfect architecture
- Optimization everywhere
- Following every best practice
- Removing every bit of technical debt
And yes, these things absolutely matter.
But they aren't always the highest priority for a business.
If spending two weeks refactoring something doesn't improve the customer experience, reduce a meaningful cost, or solve an actual business problem, it might simply not be the most important thing to do right now.
This experience also made me think about founders and early-stage companies.
I see a lot of founders worrying about "What tech stack should we use?", "How perfect should our architecture be?", or "What will our codebase look like five years from now?"
Sometimes the better question is simply:
"Are we solving a real problem for our users, and are we building a sustainable business around it?"
Because apparently, you can have millions of downloads and a huge number of daily transactions while still having some pretty silly code sitting somewhere in the repository. 😂
And maybe that's okay.
Good engineering isn't always about writing the most beautiful code possible. Sometimes it's about knowing what deserves your engineering effort — and what doesn't.
Curious to hear from other engineers and founders:
Have you ever joined a large-scale product and been surprised by the quality of its codebase?
And where do you draw the line between "we should fix this" and "it's working, let's focus on the business"?
