What a professional frontend needs and how to structure it

A frontend is not "the pretty part"

For your company's users, the frontend is the product: that is where the quotation, the sign-up or the payment is won or lost. And yet it is among the least audited parts. A system can have an impeccable backend and a frontend that nobody can maintain, that doesn't read well on a phone, that Google doesn't understand or that breaks every time the brand changes.

This is the list of what, in our judgment, a professional frontend should have, and why. It is not a recipe: it is what is worth asking of your team or your vendor, and how to tell whether it has it.

1. Components with a direction, not a folder of "things"

A professional interface is built from small, reusable pieces. React's own documentation puts it this way: a component should ideally do only one thing, and if it grows, it is split into subcomponents.

A useful vocabulary is that of Atomic Design (Brad Frost): atoms (a button, a field), molecules (a field with its label and its error) and organisms (a header, a complete form). We extend it with sections and pages when it helps to govern the product. It is a convention, not a law. What makes it valuable is a single rule: dependency flows in one direction. A basic piece does not know the product pieces that use it.

And a discipline that avoids a lot of waste: abstract late. A pattern becomes a shared component when it has already repeated and its variants have stabilized; abstracting earlier usually costs more than a visible duplicate.

Do you know today which screens change if your brand's primary color changes tomorrow?

2. A design system with tokens

A design token is, by the definition of the group that works on its format, information with a readable name: at a minimum, a name and value pair (for example, the primary text color). The principle is simple: color, typography and spacing are not written into the component; they are taken from a token. Changing the brand becomes changing one value, not editing every screen.

An honest caveat: the standard token format from the Design Tokens Community Group is still a draft, and its own text asks that it not yet be implemented. Tokens can be defined today in your system and exported when the standard stabilizes.

3. Storybook, and what is delivered with it

A component without documentation is hard to use well for anyone who did not write it. Storybook lets you build and review each component in isolation, with its variants and its hard-to-reach cases, and it works as documentation generated from the stories themselves (its autodocs feature does it from the component's metadata), so it stays close to the code; even so, it is only as good as the stories: they must reflect real use. For a company, what matters is what it receives: a browsable catalog that design, QA and the business can open, not a screenshot in a chat.

How to organize it so that it works as a contract —with hierarchy, states and reviews— we explain separately: How to structure a Storybook that works as a contract. Here, just the requirement: a catalog that depends on someone remembering to publish it falls out of date; publish it automatically when changes are approved.

4. Tests at three levels, and why one is not enough

• Unit and component tests (with Jest or its modern equivalent), which check logic and visible behavior.
• End-to-end tests (for example with Playwright), which walk through the flows that pay the bills: sign-up, quotation, payment. Its best-practices guide asks to test what the user sees and not internal details, and to keep each test isolated from the others.
• Accessibility and visual regression. Screenshot comparison helps detect a change that nobody opened, although Playwright's own documentation warns that rendering varies by operating system, browser and hardware, and that is why the references must be generated in the same environment where they are compared.

On accessibility, a limit worth saying out loud: according to Playwright's documentation, automated tests detect some common problems, but many are only discovered through manual review. Automate what can be automated and reserve human review, with keyboard and screen reader, for critical flows.

The level worth demanding is WCAG 2.2 AA. Two concrete examples from the standard: text must have a contrast of at least 4.5:1 (3:1 for large text), and elements that are tapped or clicked must measure at least 24 by 24 CSS pixels, with exceptions.

How many of your critical flows have a test that runs by itself on every change?

5. Frontend CI/CD: what must be able to be stopped

A frontend pipeline is how quality avoids depending on anyone's goodwill. At a minimum it must check style, types, tests and build, and review dependencies with known vulnerabilities (npm audit sends the description of the dependencies to the registry and returns a report of known vulnerabilities; it is a useful control, not a sufficient security analysis on its own). Each step can stop the release; the detail of how a release path is assembled is in Release without fear on your own infrastructure.

On quality analysis, what it must meet. The default quality gate of SonarQube Server, "Sonar way" (according to its current documentation; it is a product's configuration, not a universal definition of quality), sets four conditions on new code: no new issues, security hotspots reviewed, coverage of at least 80%, and duplication of 3% or less. What is valuable is the philosophy: it is not about fixing everything old, but about not adding new debt. And a nuance that matters to us: a gate that is switched off or does not run is not the same as one that passes. Insist on seeing the run, not just the color of the dashboard.

6. SEO and AI reading: content that is crawlable and verifiable

If your site is public, its important content must be accessible to a search engine and, when relevant, to AI assistants. This must be verified on the HTML that is actually delivered and rendered, not assumed. Google recommends unique, descriptive titles and each page's own descriptions, and warns that if important content is hidden behind JavaScript, it may not be understood. web.dev's guide on rendering strategies explains the trade-off: static rendering at build time offers the best response times, although it scales poorly with many unique URLs; client-side rendering requires watching the weight of the JavaScript.

On that basis, three practices: structured data in JSON-LD (the format Google recommends as the easiest to maintain at scale), one canonical address per page to avoid duplicates and, if there are several languages, the declaration of alternate versions per language (these are two distinct mechanisms). And one proposal, llms.txt, which offers agents a summary of the site in Markdown. It is not an official standard: it is an open community proposal, and different AI agents behave differently, so there is no universal requirement as there is for search engines. The best condition is that these checks be part of the build and not a list that someone remembers at the end.

7. Performance: measured by what the user experiences

Google defines three experience signals, evaluated at the 75th percentile of page loads, segmented between mobile and desktop. They are measured with the real usage of your users; a test on a single machine gives guidance but does not replace that measurement:

• LCP (how fast the main content appears): 2.5 seconds or less.
• INP (how fast it responds to a tap or a keystroke): 200 milliseconds or less.
• CLS (how much the content moves while loading): 0.1 or less.

Two engineering ideas underpin those numbers. The first: do not load up front what is not used up front. React allows splitting the code and loading a component only when it is needed.

// Illustrative, taken from the React documentation (lazy + Suspense).
const VistaPrevia = lazy(() => import('./VistaPrevia.js'));

<Suspense fallback={<Cargando />}>
  <VistaPrevia />
</Suspense>

The second: do not apply that idea to what the user sees first. According to web.dev, the LCP candidate image should never be lazy-loaded, because that delays exactly what the signal measures.

8. Security: the browser is hostile territory

Everything that reaches the browser is public; no secret lives there. Two central ideas:

• XSS. React escapes by default what it renders, but it offers an escape hatch, dangerouslySetInnerHTML, which its own documentation calls dangerous: with untrusted content it is trivial to introduce a vulnerability. OWASP recommends sanitizing with a specialized library, and warns that no single technique prevents XSS.
• Defense in depth. A content security policy (CSP) restricts what the page's code can do (where it loads resources from and where it connects, among other things) and helps against XSS and clickjacking. MDN is clear: it does not replace sanitization; it is used in addition to it.

And a simple rule of judgment: do not leave in the browser, readable by any script, reusable credentials or sensitive data. And do not forget that client-side validation never replaces server-side validation: authorization is always decided on the server.

9. After release: resilience and observability

A professional frontend assumes that something will fail. Every call to a service has its loading, empty, error and retry states, and a failure is shown, not hidden behind a blank screen. And someone must find out about the error before the customer reports it: browser errors captured with minimal context and without personal data, and the performance signals from section 7 monitored with real users. If the site loads analytics or third-party tags, they are code too: they weigh on performance and must stay within budget.

It is also worth agreeing on what is supported: browsers, modest devices and slow networks. A design system, finally, needs an owner, versions and a way to retire components without breaking those who use them.

What evidence to ask for before approving

For a committee, a frontend is approved with evidence, not with a demo. Ask for: the published component catalog; the test report of the latest release, with its count read from the summary; the quality gate result with the condition that failed, if it failed; the accessibility review, including the manual part; the performance signals with real data; and who authorizes an exception and how it is recorded.

What almost every team postpones

Two things: end-to-end tests of all critical flows, and having an accessibility failure stop publication instead of merely warning. A control that cannot stop a change is a suggestion. We say it because denying it does not fix it, and because it is exactly what is worth asking any team, yours included.

Closing

A professional frontend is not recognized by its appearance on launch day, but by what it withstands afterwards: a brand change, an auditor, a modest phone, a search engine, an attacker. When that fails, the cost is not technical: it is lost sales, rework and an audit that is hard to pass. At Hábil we are experts in this. We build your product's frontend with governed components, design system, tests, accessibility, performance and security reviewed on every change, and we can start by checking your priority digital journey against this list.