How to choose a front-end development agency for a SaaS product

Choose the partner that can show you, in working code, how it handles the parts of a SaaS interface that screenshots hide: loading, empty, error and no-permission states, keyboard and screen-reader use, speed with realistic data, shared components, and the tests that keep all of it working. A portfolio of finished screens cannot tell you that. A walkthrough of a shipped product, a look at real code and a small paid piece of work can. Keep design and front-end engineering with one team while the product's behaviour is still being decided; split them only when that behaviour is written down well enough that engineers do not have to guess.

Tcules offers both product design and front-end engineering, so we have an interest in that last point. This guide names no other firm, and every check in it works whoever you hire, us included.

What good front-end work on a SaaS product includes

A SaaS front end is not a marketing site with a login. People use it daily, it changes with their role and their data, and it depends on services that are sometimes slow or wrong. Good work shows in six areas, and each one leaves evidence you can ask to see before you sign.

Three of these areas are where a promise is easiest to accept in place of proof.

Accessibility. On the public web, failure is the common case. WebAIM's 2026 analysis of the top one million home pages found detectable WCAG failures on 95.9% of them, with low-contrast text on 83.9%. Those are public home pages rather than logged-in products, and automated tools catch only part of the problem, so treat the figure as a sign that accessibility does not happen by default, not as a measure of SaaS apps. For a SaaS interface, several of the criteria added in WCAG 2.2 bite directly: Dragging Movements (a kanban board or a reorderable list needs a non-drag alternative), Focus Not Obscured (sticky headers and toasts must not entirely hide the focused element), Target Size, and Accessible Authentication for the login. If you sell to public-sector or large enterprise buyers, you may be asked for an Accessibility Conformance Report, the document produced by testing a product against ITI's VPAT template. Ask whether the partner has built work that supported one.

Performance. Google's Core Web Vitals set "good" at 2.5 seconds or less for Largest Contentful Paint, 200 milliseconds or less for Interaction to Next Paint (INP) and 0.1 or less for Cumulative Layout Shift, at the 75th percentile of page loads. In a SaaS product, we would give INP the most attention, because the work is in filtering, editing and saving rather than in the first load. Google's own guidance says INP is best measured from real users in the field, and that some lab tools report nothing for it because they only watch the page load. A partner who answers "performance" with a single lab score on an empty page has not measured what your users will feel. Ask what happens on your largest real table.

Tests. The principle behind Testing Library, written by Kent C. Dodds, is that "the more your tests resemble the way your software is used, the more confidence they can give you". In practice that means tests that click, type and read the screen, including a test that signs in as a role without permission and checks what that person sees. Visual comparison tools are useful for finding candidate differences; a person still has to decide which ones are defects.

For components, the vendor-neutral format for sharing design values between design tools and code reached its first stable version in October 2025, so "one source for colour, spacing and type" is now a reasonable thing to ask for rather than a custom arrangement. The method for keeping a coded build true to the design is set out in how to keep a React build true to the Figma design.

Questions that separate one partner from another

The hiring guides that rank for this search ask about years in business, portfolio, stack and price. Those questions screen out weak firms. The ones below separate the good ones.

1. "Can you show us a shipped SaaS screen in its empty, error and no-permission states?" A strong partner opens a running product or its component library and shows them. A weak one shows the populated, happy-path screen again.
2. "Who will write the code, and will those people stay on the work?" You want names and roles, and the people in the pitch should be the people doing the work.
3. "What do you do when the design does not cover a state?" Listen for a process: they raise it, propose an answer, get a decision from someone who owns the product, and record it. "We'll handle it" means the decision will be made silently in code.
4. "How do you test accessibility?" A credible answer combines automated checks with a person working through flows by keyboard and with a screen reader, on components and on whole journeys. "We run a scanner at the end" is not enough.
5. "How do you measure performance, and with what data?" Look for realistic data volumes, interaction timing on the heavy screens, and monitoring after release.
6. "How do you use AI coding tools, and how is their output reviewed?" In Stack Overflow's 2026 developer survey, 73% of respondents said they use AI coding assistants or agents daily at work, and 48% said they trust AI when they can easily validate its answers. Ask the partner what their validation is: the states, the accessibility checks, the tests and the human review that generated code has to pass. We set out what that review is for in accepting AI-generated front-end code.
7. "How will you work with our engineers?" Their pull requests should go through your review, follow your conventions and leave your team able to change the code without them.
8. "Where does the code live, who owns it, and what do we have at the end?" The answer you want: your repository and accounts from the first day, ownership of the work as agreed in the contract, documentation, and a handover your team could carry out.

Warning signs

• A portfolio of marketing sites and static screens. It shows visual skill, not the ability to build an authenticated product with roles, permissions and live data.
• A quote before any questions about roles, data, back-end readiness, browser support or accessibility target. Those are the things that make the work larger or smaller, so a quote that ignores them is a guess.
• "Pixel-perfect" as the main promise. A screen can match the mock-up and still break for a keyboard user, mislead when empty or strand someone without permission.
• Accessibility offered as a final audit or a plug-in overlay. Accessibility that is not in the components has to be retrofitted into every screen.
• A framework recommended before they have seen your codebase or met your team. The right choice depends on what you already run and who will maintain it.
• Tests promised "at the end". Tests written after the build risk describing what was built rather than what was intended.
• Code kept in their accounts during the work. You should be able to see, run and review the code throughout.
• Senior people in the pitch who are not on the work. Ask who joins the first sprint.

Should design and front-end engineering sit with one team?

The case for one team rests on where behaviour gets lost. In a study presented at CSCW 2017, Nolwenn Maudet and colleagues drew on 16 interviews and found that current designer-developer practices caused unnecessary rework and differences between the original design and the build. They traced three recurring breakdowns: designers left out critical details, missed edge cases or overlooked technical limits. In two design meetings they observed, bringing the developer in early reduced potential breakdowns, but new ones appeared as the project progressed. In our reading, those three gaps correspond to the states, accessibility and performance rows in the table above.

An older observation points the same way. Melvin Conway argued in 1968 that organisations designing systems are "constrained to produce designs which are copies of the communication structures of these organizations". Our inference, not a finding of either source: every organisational boundary a product decision has to cross is another place for it to be simplified or dropped, so fewer boundaries help most when there are many decisions still to make.

That gives a practical rule.

Keep design and front-end engineering with one team when:

• you are building a new product or a major capability whose interactions are still being decided;
• the workflows are data-rich and change by role, permission or record state;
• you have no working design system, so components and their states are being defined as you go;
• no designer on your side can stay available, day to day, through the build.

Hiring front-end engineering on its own is reasonable when:

• your design team already maintains a design system with components, states and rules;
• screens are specified with their states and content limits, not only the happy path;
• your designers can review the work in the browser every week and settle disagreements quickly.

If you split the work, write four things into the engagement: a shared component library, states in every specification, joint reviews in the running product rather than over screenshots, and one named person who decides when design and code disagree. The same problem from the design side, keeping product knowledge when design is outsourced, is covered in how to outsource UX design without losing product knowledge.

To tell whether a studio genuinely does both, pick one past project and ask who designed the states and who wrote the components, whether designers reviewed the work in the browser, and whether the design files and the component code share the same design values. A firm that has two departments under one name will answer those questions differently from one where the work moved between the same people.

What changes the size of the quote

Prices vary too much by scope and model to be useful in a guide, but the same drivers come up again and again. Expect the work to grow with:

• the number of roles and permission levels, because each one multiplies the states a screen has to handle;
• data volume and live updates, which turn simple tables into performance work;
• how mature your design system is: complete, partial or absent;
• the accessibility target, and whether you need evidence for a conformance report;
• the browsers, devices and screen sizes you support;
• how ready the back end is: stable, documented and possible to mock, or still changing;
• the test coverage you expect and who maintains it afterwards;
• whether product design is part of the scope.

The shape of the engagement matters too: a fixed slice of the product, a team working inside your sprints, or a longer build with continuing support. A firm that cannot explain which of these drivers moved its quote has probably not looked at them.

A selection process that produces evidence

1. Write a one-page brief. Name the hardest screen, the roles that use it, realistic data volumes, your accessibility target, your stack and where the code will live. Firms that read it carefully will ask better questions.
2. Shortlist three and run the walkthrough. Use the questions above and ask each firm to show, not describe. Then speak to one client from a past SaaS project and ask what happened when the design did not cover a state.
3. Pay for a small slice. One real screen, in every state, with tests, in your repository, reviewed by your engineers. It is the closest you can get to working with them before you commit.
4. Decide on what the slice showed. Compare the code, the tests, how they handled the questions the design did not answer, and how easy they were to review.

Where Tcules fits

Tcules is a digital product design studio creating ambitious new software products and making established ones better. Product Design is the foundation of the practice, extended by Design Engineering and Software Development, with a particular focus on SaaS. That means we can hold design and front-end engineering in one team, which is the arrangement this guide recommends while behaviour is still being decided, and we said so at the start for that reason.

Our front-end development work treats acceptance as more than visual resemblance: it covers structure, state, content, interaction, accessibility and runtime behaviour, and it can sit inside your existing architecture. Put the questions above to us as you would to anyone else.