12 Questions to Ask a React Agency Before You Sign a Contract
by Maven Team, Software Development
Hiring a React development agency is a five- or six-figure decision that shapes your product roadmap for years. Get it right and you ship faster than you thought possible. Get it wrong and you spend the next twelve months either rewriting the agency's code or unwinding decisions you cannot undo.
The problem is that almost every agency website says the same things: "we are pixel-perfect specialists", "we ship fast", "we obsess over quality". These claims are unfalsifiable. They are not selection criteria.
The questions below are. We have been on the answering side of these questions for years, and we know which ones make agencies squirm. If your shortlist cannot answer them clearly, that is your answer.
1. Who specifically will write the code?
Most agency pitches feature the senior team. Most agency engagements are delivered by whoever is on the bench. This is the single biggest gap between what is sold and what is delivered.
Ask for the names, LinkedIn profiles, and years of React experience for every engineer who will touch your codebase. Not "a senior engineer" — names. If the agency hedges ("our staffing depends on project timing"), you have your answer: you will get juniors and you will pay senior rates.
Follow up: what is your bench engineer's average years of React experience? Anything under 4 years should make you cautious. Anything under 2 years means you are subsidising someone's training.
2. Can I see three projects you shipped in the last 18 months?
Not three case studies — three production URLs you can open in a browser today. Sites you can inspect with DevTools. Apps you can actually use.
Agencies hide behind NDA-protected portfolios. Some of that is legitimate; most of it is a tell. Maven, for instance, has shipped publicly visible work that you can probe — the bundle size, the Core Web Vitals, the React version, the accessibility scores. If your shortlist cannot produce three live URLs, ask why.
3. What is your test coverage philosophy?
There is no single right answer here. There are several wrong ones.
Wrong: "We achieve 100% test coverage." Coverage as a target produces coverage-theatre tests that pass without testing anything useful.
Wrong: "Tests slow us down, so we don't write them." This is what cheap agencies say.
Right answers sound like: "We write integration tests around critical user flows, unit tests for non-trivial logic, and snapshot tests sparingly. We aim for confidence, not coverage percentages."
The follow-up question is more revealing: "Show me the last test you wrote that caught a real bug." If they cannot give you a concrete example within 30 seconds, they do not actually write tests.
4. How do you handle accessibility?
A good agency does not say "we follow WCAG". A good agency says something like: "We test with VoiceOver and NVDA, run axe-core in CI, audit colour contrast in Figma, and treat keyboard navigation as a P1 requirement, not a polish item."
The UK Equality Act 2010 makes inaccessible commercial websites a legal risk. If your agency treats accessibility as an end-of-project add-on, they are setting you up for either remediation work or worse — a public complaint.
Bonus question: "How do you handle focus management on route changes in a single-page app?" This is a one-line tell. Anyone who works on accessibility seriously knows the answer ("we move focus to the new page's H1 or a designated landmark"). Anyone who doesn't will improvise something vague.
5. What is your incident response process?
A site running React in production will, at some point, throw an unexpected error. What happens then?
Ask:
- How will you know about it? (Sentry? Datadog? CloudWatch alarms?)
- Who gets paged?
- What is your typical time-to-detect, and time-to-resolve?
- Do you offer support after launch, and on what SLA?
Many agencies "deliver the code and walk away". That model is fine if you have a senior in-house team ready to take over on day one. If you do not, you need an agency with a real post-launch support offering — or a clear handover plan documented in the contract.
6. How do you scope and price a project?
The answers fall into three buckets, each with different implications:
Fixed-price, fixed-scope. Lower risk on cost; higher risk on quality if the scope is squeezed. Works for well-defined projects with stable requirements.
Time-and-materials. Pay for hours worked. More transparent, but exposes you to scope creep and slow-walked delivery. Only works if you trust the agency and have someone monitoring velocity.
Milestone-based / sprint-based. A hybrid. Fixed scope per sprint, with the freedom to re-prioritise the next sprint. This is what good agencies tend to default to for projects over £50,000.
The wrong answer is "We tell you the price once we start." Walk away.
7. How do you handle disagreements about technical direction?
You will disagree at some point. It happens on every engagement. The question is what happens when you do.
Healthy answers acknowledge that the agency will sometimes push back ("we will tell you when we think you are wrong, with reasoning, in writing") and that the final call rests with you ("but you are the client and we will implement what you decide, with the trade-offs documented").
Unhealthy answers are either total deference ("we just do what you ask") — which means you are paying for typists, not engineers — or total inflexibility ("we know best") — which means you will spend the engagement litigating decisions instead of shipping.
8. What is your bus factor for our project?
If the lead engineer on your project quits tomorrow, what happens? How long until a new engineer is productive on your codebase? Is the documentation good enough for someone outside the team to land changes in week one?
The right answer involves: written architectural decision records (ADRs), inline documentation, README files that explain how to run the project locally, and at least two engineers familiar with your stack at any time.
The wrong answer is hand-waving about "we have good processes". Ask for an artefact — a sample ADR, an onboarding doc, a runbook. Agencies who do this well have these things ready to show.
9. Show me your CI/CD pipeline.
Ask the agency to walk you through a recent pull request from a recent project. Specifically:
- What automated checks run on every PR? (Lint, type-check, unit tests, integration tests, bundle-size budget, Lighthouse, accessibility scans?)
- How long does the pipeline take?
- Do you have preview environments per PR? Can stakeholders review changes before merge?
- How do you deploy to production? Is it automated, or manual?
- What does rollback look like?
An agency with no CI or with manual deploys is, in 2026, telling you they are not a serious technical operation. This is non-negotiable.
10. How do you handle the hardest part of any project — the data layer?
UI is the visible part. The data layer is where most React projects actually struggle. Ask:
- What is your default approach to fetching data? (React Query/TanStack Query, RTK Query, native fetch in
useEffect?) - How do you handle authentication and authorisation in the frontend?
- How do you handle optimistic updates, retries, and error states?
- How do you think about loading skeletons vs spinners vs incremental rendering?
The answer should be opinionated and specific. Vague answers ("we choose the right tool for the job") usually mean "we make it up each time and the code ends up inconsistent".
11. What does your handover process look like?
Eventually, whether you continue with the agency or take the code in-house, you will need to operate it without them. What does that look like?
A serious agency will hand over:
- A README that gets a new engineer running locally in under 30 minutes
- A documented deployment process
- A runbook for common incidents
- Architectural decision records
- A list of every third-party service (Stripe, Auth0, Algolia, etc.) with credentials securely transferred
- A "known unfinished things" document — be wary of agencies who say everything is perfect
Ask to see a sample handover pack from a recent project. Many agencies cannot produce one because they never make them.
12. Why did your last client stop working with you?
This is the unfair question. Every agency hates it. Most will hedge.
The honest answer sounds like: "Our last engagement ended in April. We had been working together for 18 months, finished the platform we set out to build, and they took it in-house. We do a 6-month support contract with them now."
The dishonest answer is a deflection: "Oh, all our clients love us, we have great relationships." Push: "Then specifically — why is the last one no longer paying you?"
If the agency cannot tell you a concrete, specific story, they are either lying or churning clients in a way they cannot articulate. Both are bad signs.
What good agencies do when they hear these questions
They smile and answer them concretely. They probably have versions of the answers ready, because they have been asked before. They use specifics — names, dates, numbers, URLs — not generalities.
What weaker agencies do is hedge, redirect, or get defensive. If you ask question 1 and the answer is "we'll figure out staffing closer to kick-off", that is a complete answer in itself. It tells you the engagement will not be staffed the way the sales pitch implies.
The agency you want will treat these questions as evidence that you are a serious buyer they want to work with, not as a hostile interrogation.
What we would do differently
Honestly, the question we wish more buyers would ask us is:
"What would you tell a friend hiring an agency for the first time, that we should be asking?"
Most agencies, including ours, have a few hard-won lessons we would happily share if anyone asked. Buyers rarely do, because they assume we will all give a self-serving answer. We won't — for the same reason a doctor will tell you to get a second opinion before major surgery. The agency that wins a bad engagement is the one that loses it loudly when it goes wrong.
If you are evaluating React agencies — including us — we will happily walk you through how we would answer all twelve questions on a 20-minute call. No pitch deck, no sales follow-up, no obligation. The point is to help you ask better questions of everyone on your shortlist, not just us.
Book a call here, or if you want a more substantial, written, independent review of an agency proposal you have already received, our £2,500 React Codebase Audit is built exactly for that.