The Hidden Cost of 'It Works'
There’s a big difference between:
- It works locally
- It works in production
- It works long term
And I was lucky — early in my career, seniors and mentors insisted on something I didn’t fully appreciate at the time:
Always handle errors.
Always think about failure states.
Early Lessons: Defensive Frontend
From the beginning, I was taught to:
- Wrap async logic in
try/catch - Handle error states inside custom hooks
- Show proper toast/notification feedback to users
- Never assume the API call will succeed
Later, on CMS‑driven projects, this evolved into:
- Using Error Boundaries for fallback UI
- Designing proper loading states
- Preventing the UI from breaking when content wasn’t perfectly configured
And then TypeScript added another safety net — making assumptions explicit and reducing entire classes of runtime issues.
But even with all that…
Production still finds ways to surprise you.
When “It Works” Breaks
I’ve had features that:
- Worked perfectly locally
- Passed PR
- Looked clean and well-structured
And then failed in production because of:
- Permission mismatches
- CMS-driven edge cases
- Race conditions
- Subtle stale state issues in
useEffect - Pagination quirks in Ant Design’s List component
None of them were dramatic.
All of them were real.
That’s the difference between code that works in isolation and systems that behave under real user pressure.
Observability Changes the Game
When I first used Sentry for error logging, I discovered errors I didn’t even know existed.
Recently, using Vercel analytics and performance insights on personal projects reinforced the same lesson:
Production tells you the truth.
One belief I’ve developed over time:
Shipping without observability is just hoping.
Now that I have production access at work, I’m calmer when something breaks — because I can inspect it, trace it, and fix it faster.
That’s maturity in frontend engineering.
Not avoiding bugs.
Reducing uncertainty.
The Senior Shift
The real shift over time wasn’t about writing smarter code.
It was about thinking in systems:
- What happens if this request fails?
- What if the CMS content is incomplete?
- What if pagination indexes shift?
- Will this still make sense in 6 months?
- Can someone else maintain this easily?
“It works” is a milestone.
“It works long term” is engineering.
