Tutorials get you to working. Production requires something more.
After shipping UIs for clients across e-commerce, fintech,
healthcare, and SaaS — here's what actually matters when
you're building for real users.
PERFORMANCE IS A FEATURE, NOT AN AFTERTHOUGHT
The number one thing clients notice is speed. Not the tech stack,
not the component library, not the animation library.
Speed.
In React, this means being deliberate about re-renders.
useCallback and useMemo exist for a reason — not to use
everywhere, but to use where a component is expensive and
re-rendering unnecessarily.
In Angular, it means understanding change detection. Default
change detection checks everything on every event. Switch to
OnPush for components that only depend on inputs and watch
your app get noticeably faster.
Code splitting is non-negotiable on anything bigger than a
landing page. Lazy load routes. Don't ship the entire app
on the first page load.
STATE MANAGEMENT: USE LESS OF IT
Every project I've inherited with Redux or NgRx had at least
30% of its state in global store that had no business being there.
UI state — loading spinners, modal open/closed, form values —
belongs in component state. Server state belongs in a fetching
library like React Query or Angular's HttpClient with proper
caching. Global store is for genuinely global state — auth,
user preferences, things that need to persist across the whole app.
Mixing these up creates codebases that are hard to follow,
hard to debug, and painful to change.
ERROR BOUNDARIES AND FALLBACKS ARE NOT OPTIONAL
In React, an unhandled error in a component crashes the entire tree.
Error boundaries catch these and show a fallback instead of
a blank white screen.
Every major section of a production React app should be wrapped
in an error boundary. Not just the root — individual sections,
so one broken widget doesn't take down the whole page.
Angular handles this differently with global error handlers
but the principle is the same — catch errors gracefully,
show something useful, log what happened.
ACCESSIBILITY IS NOT EXTRA WORK
Semantic HTML, proper ARIA labels, keyboard navigation —
this isn't a nice-to-have. It's part of building something
that works.
It also makes your components more testable, your markup more
readable, and your SEO better. There's no downside.
Add it from the start. Retrofitting accessibility into a large
codebase is painful. Doing it right the first time takes
maybe 10% more time.
TESTING: WHAT ACTUALLY GETS TESTED IN PRODUCTION APPS
I'm not going to tell you to write tests for everything.
Nobody does and it's not realistic on most freelance timelines.
But some things always get tests:
Utility functions and business logic. Pure functions are easy
to test and bugs here cause the most damage.
Critical user flows. Login, checkout, form submission.
If these break, the product doesn't work.
API integration layer. Mock the API, test that your app
handles success and error responses correctly.
Everything else — judgment call based on how likely it is
to break and how bad it would be if it did.
Production UI work is a different skill set from building
tutorial apps. The gap is mostly discipline — performance
habits, error handling, accessibility, sensible state management.
If you need a frontend built to production standards —
that's what I do. Get in touch.
