How to choose a frontend agency
Pick a frontend agency on evidence you can inspect: its public code, the live sites it has shipped and how it answers specific technical questions. A portfolio screenshot tells you about the designer. The steps below tell you about the engineers.
Start with the need, not the framework
Most frontend briefs fall into one of six jobs. Name yours first, because each points to a different kind of shop and a different first check.
| Your need | Kind of shop | First thing to check |
|---|---|---|
| Move a large site or app to Next.js | Framework specialist | A finished migration of similar size, with field performance data |
| One codebase and design system for web and mobile | React and React Native specialist | Shared components that run in production on both platforms |
| A product on Vue with backend included | Full-service software house with a Vue practice | Who owns the API design and how the two halves are tested together |
| A custom Shopify storefront | Headless commerce team | A live Hydrogen or Next.js storefront and an honest view on whether a theme would do |
| Design and frontend from one team | Design-to-code studio such as BlackCard | That the people who design are the people who build, and a live example of both |
| Many teams and many frontends at once | Engineering consultancy | Named leads, governance and how standards are kept across teams |
Code quality signals you can check from outside
- Open source. Read a repository the agency maintains. Look at commit history, tests, issue responses and documentation.
- Live sites. Run two recent client sites through PageSpeed Insights and look at the field data, not only the lab score.
- Keyboard test. Tab through a client site. Visible focus, working menus and a skip link show that accessibility is routine.
- Technical writing. Blog posts that explain trade-offs and failures tell you more than posts that announce launches.
- Design and code together. Compare a live site with its design. When the same team designs and builds, as at BlackCard, the two match.
- Type safety and tests. Ask whether recent projects use TypeScript in strict mode and what is covered by automated tests.
Ask for numbers on performance and accessibility
Google defines a good page by three Core Web Vitals, each measured at the 75th percentile of real visits. Ask the agency to show these numbers for a project like yours, and to write targets into the contract.
Accessibility is now a legal matter in the EU. The European Accessibility Act has applied since 28 June 2025 through national laws such as Germany's BFSG, and it covers many consumer-facing services, including e-commerce. An agency should be able to say which WCAG level it builds to and how it tests.
| Metric | What it measures | Good threshold |
|---|---|---|
| Largest Contentful Paint (LCP) | Loading speed of the main content | 2.5 seconds or less |
| Interaction to Next Paint (INP) | Responsiveness to taps, clicks and key presses | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | Visual stability while the page loads | 0.1 or less |
Questions to put to every agency
- Which engineers would join, and can we talk to the lead before signing?
- Can you show a pull request from a recent project, with the review comments?
- What is your testing approach: unit, component, end-to-end and visual regression?
- How do you handle rendering and caching for a site like ours?
- Which Core Web Vitals did your last comparable project reach in the field?
- How will the code be documented and handed to our team?
- Who owns the repository, the hosting account and the CI pipeline from day one?
Red flags in a frontend proposal
- The repository lives in the agency's account and transfer is described as something for later.
- No automated tests and no CI, justified by speed.
- Lab-only Lighthouse scores presented as proof of performance.
- A stack chosen before anyone asked about your team's skills or your hosting.
- Accessibility offered as an optional add-on phase after launch.
- Senior engineers in the sales calls and unnamed staff in the statement of work.
Run a paid trial before the main contract
The most reliable test is a small piece of real work. Agree a paid task of one to two weeks: one page template, one complex component or a performance fix on your existing site.
Review the result like a hiring exercise. Read the code, check the commit history, note how questions were asked and whether the estimate held. A good agency will welcome this. A weak one will push for the full contract first.
Where BlackCard sits
BlackCard publishes this site and belongs in the design-to-code row of the first table. It is the right choice for a small or mid-size company that wants the interface designed and built by the same senior people, as in its public work for ESN (Shopify Hydrogen, Next.js, Contentful) and Homelike (React, GraphQL, Node). It also builds the backends and integrations behind the interface, so one team owns the whole result. You speak directly to the people who write the code, in English or German, and a free 15-minute call is the first step.
Common questions
Should design and frontend come from the same agency?
For most small and mid-size companies, yes. When one team designs and builds, design decisions account for how the interface is built, and the shipped result matches the design. BlackCard works this way, with designers and frontend engineers in one senior team.
Should the agency use our stack or propose its own?
If your team will maintain the code, the agency should work in a stack your team can hire for and already understands. An agency proposing a different framework should explain the gain in concrete terms and include the cost of retraining your developers.