Before the contract, not after
Contract review is the wrong time to discover misalignment. By then, there's budget committed, timelines set, stakeholders briefed. The conversation becomes awkward in proportion to how much has already been decided.
The questions in this post are designed for the evaluation phase — when you still have leverage, when switching cost is low, when a bad answer can change your decision rather than just your mood.
Most of them won't appear in any contract template. They're the things that determine whether the work actually goes well, which is a different question from whether the contract is technically enforceable.
1. Who specifically will be working on this?
This is the question vendors dislike most, which is exactly why it matters.
Proposals are written by senior people. Discovery calls are run by senior people. The work is often done by whoever's available. This isn't necessarily bad faith — it's how most agencies operate. But if you're making a decision partly on the basis of the team you met, you need to know whether that team is the one that will be doing the work.
Ask for the names and LinkedIn profiles of the React developers who'll be assigned. Ask what their current project load is. Ask what happens to your project if one of them leaves mid-engagement.
If you're looking to hire React.js developers through a vendor or staff augmentation partner, this question becomes even more pointed: you should be able to interview the specific people, not just the company's representative sample.
The answer tells you a lot. Vendors who are confident in their team answer immediately. Vendors who hedge are usually telling you something they haven't said out loud.
2. How do you handle state management for apps at our scale?
This is a technical screen disguised as a contract conversation, and it's one of the most useful ones.
You're not testing whether they know what Redux is. You're testing whether they have opinions — whether they've built enough React at scale to know that the answer depends on the application, not on a preferred library. A vendor that says "we use Redux for everything" or "we use Context for everything" hasn't thought hard enough about the tradeoff.
The answer you're looking for is something like: "It depends on what the state represents. We use React Query or SWR for server state, keep UI state local unless it needs to be shared, and reach for something like Zustand or Redux Toolkit only when genuinely global state has enough complexity to justify it."
If they can't give that answer without prompting, it's a signal. State management is one of the decisions that's cheapest to make well on day one and most expensive to change at month six.
3. What does your handover process look like?
This question surfaces assumptions that neither party has made explicit.
Some vendors deliver a production deployment and consider the engagement complete. Some deliver a codebase and documentation. Some include a knowledge transfer period. Some assume ongoing maintenance is part of the relationship. None of these is wrong by default, but they produce very different outcomes depending on your internal capacity.
If you have an in-house engineering team that will own the codebase after delivery, you need documentation, test coverage, and a structured handover period. If you don't have that team yet, you need to know what ongoing support costs and what it covers.
Ask specifically: what test coverage will be in place at delivery? What documentation will exist? Who on your team will we be able to talk to after launch if something breaks?
A vendor that hasn't thought about this will give you a vague answer. That vagueness will cost you later.
4. How do you handle performance requirements?
This is less about whether they can build a fast app and more about whether they measure it.
The right answer involves specific tooling: Lighthouse scores, Core Web Vitals targets, React DevTools profiling, bundle size budgets enforced in CI. Vendors who build performant React apps tend to have a process for it. Vendors who don't tend to notice performance problems the same way users do — after the fact, when someone complains.
Ask what performance targets they're committing to. Ask how bundle size is monitored across the project. Ask how they handle code splitting for large route trees. If they look confused by "Core Web Vitals," that's your answer.
For enterprise apps, initial load time and interaction latency are often more consequential than any individual feature. The contract should reflect that.
5. What's your approach to accessibility?
Most vendors will say "we follow WCAG guidelines." Ask which level. Ask how they test it — manual testing with a screen reader, automated tools like axe, or both. Ask whether accessibility is built in from the start or audited at the end.
The reason this matters in a contract conversation: retrofitting accessibility onto a React codebase that wasn't built with it in mind is expensive. Semantic HTML, ARIA labels, keyboard navigation, focus management — these are much easier to get right during development than to add afterward.
If accessibility is a compliance requirement for your product (and in many enterprise contexts, it is), it belongs as an explicit deliverable in the contract with specific acceptance criteria. Not "WCAG compliant" in general — which level, how tested, by whom.
6. How do you manage architecture decisions during the engagement?
This one is about process, not technology.
React projects go sideways not because the wrong library was picked upfront but because architectural drift happens without anyone noticing. A folder structure that made sense at week two doesn't scale to week twelve. A state management pattern that worked for three screens starts to break at twenty. Without a process for catching and addressing these shifts, they compound into the kind of debt that requires months of rework.
Ask how architectural decisions are documented. Ask who has the authority to make them. Ask how they handle a situation where an early decision turns out to be wrong.
Good answers involve architecture decision records (ADRs), regular review points, and a willingness to revisit early choices. Bad answers sound like "our senior dev handles that" with no further structure.
7. What happens when something breaks in production?
You want a service level agreement here, but you also want to understand how they think about production.
Ask for the support tier structure: what response times are guaranteed, what counts as a severity-one incident, how escalation works. Ask whether they have on-call coverage or whether production issues queue until business hours. Ask what the process is for a critical bug that ships in a release they delivered.
For any company considering engaging external React.js development services long-term, the production support model is often what separates a partner from a vendor. A vendor ships and moves on. A partner has skin in the outcome.
This is a particularly important question if your internal team doesn't have deep React experience — because the answer tells you whether you'll be on your own when things go wrong.
8. Can we see a real codebase sample — not a portfolio piece?
Portfolio projects are optimized for presentation. They tend to have clean architecture, good test coverage, and tidy documentation, because they were built specifically to be shown to people like you.
What you actually want to see is the code they wrote under real deadline pressure, for a real client, with real changing requirements. That's the code your project will look like.
Most vendors won't hand this over without client permission, which is reasonable. But the willingness to try — to offer a sanitized excerpt, or to arrange a reference call where you can ask their past client's engineers directly about code quality — tells you something. Vendors confident in their work will find a way. Vendors who aren't will redirect you to the portfolio.
9. How do you handle changes to scope mid-project?
This is where most project relationships go wrong, and most contracts are vague about it.
There are three common models: fixed scope where changes go through a formal change-order process, time-and-materials where any direction change is just billed hourly, and a hybrid where a core scope is fixed but an allocated change budget provides flexibility.
None of these is inherently right. What matters is that both parties understand which model applies and what the implications are. A fixed-scope contract sounds safer but tends to produce adversarial conversations whenever requirements evolve — and requirements always evolve.
Ask what their default model is. Ask for a specific example of a scope change from a recent project and how it was handled. The example will tell you more than the policy.
10. What's your hiring and retention model for React developers?
This matters more than most CTOs think to ask.
For a vendor, high turnover means mid-project team changes, knowledge loss, and ramp-up costs that don't show up on your invoice but absolutely show up in velocity. For a staff augmentation model where you hire React.js developers through a partner, it determines how stable your team will actually be.
Ask what their average developer tenure is. Ask how they handle attrition mid-project — who absorbs the cost of onboarding a replacement, and how long the context transfer takes. Ask whether the developers assigned to your project are employees or contractors, and what that means for continuity.
The vendors with stable, well-retained teams will talk about this easily. The ones with churn problems will give you generalities about "strong culture."
The contract clause most teams forget
Beyond these questions, one clause is worth fighting for specifically in React development contracts: a code quality standard with teeth.
Most contracts include something like "work will be delivered in a professional manner" — which is unenforceable. What you want is specific: test coverage minimum (70% or better for business logic), documented ADRs for architectural decisions, Lighthouse performance scores above a set threshold at launch, zero WCAG AA violations on core user flows.
These aren't punitive. They're just the conditions under which you'll accept the work. Vendors who build quality React apps will agree to them without hesitation. Vendors who are used to shipping and moving on will push back — which is information you want before signing, not after.
Key takeaways
- Ask who specifically will be working on the project, not who the vendor would prefer to talk about.
- Technical questions about state management and performance belong in the evaluation conversation, not in a post-contract discovery call.
- Accessibility and test coverage should be acceptance criteria, not assumptions.
- The production support model defines whether you have a vendor or a partner.
- When you hire React.js developers through any external model, stability and retention matter as much as seniority.
- Scope change handling is where most project relationships break down. Understand the model before you sign.
- A code quality clause with measurable thresholds is the single most protective thing you can add to a React development contract.
FAQs
What's a reasonable timeline to expect for a mid-complexity React.js application?
A mid-complexity app — authenticated user flows, a REST API integration, a few dashboard views — typically runs 10–16 weeks with a competent team of three to four engineers. Timelines below 8 weeks for anything with real backend integration should trigger scrutiny. Not because it's impossible, but because cutting time on a mid-complexity project usually means cutting scope, testing, or architecture quality, and it's worth knowing which.
Should we hire React.js developers in-house or use an external vendor for our first build?
It depends on whether you intend to own the codebase long-term. If yes, in-house or staff augmentation makes more sense — you're building institutional knowledge alongside the product. If this is a one-time build that will then be maintained by a small internal team, an external vendor with a structured handover is reasonable, provided the handover terms are explicit in the contract.
How much test coverage should we require in a React development contract?
For business logic — hooks, utility functions, state management — 70% coverage is a defensible minimum. UI component coverage is harder to specify because snapshot tests can inflate the number without adding real value. A better requirement: integration tests covering all critical user flows, unit tests on all hooks and utility functions, and a testing approach documented in the README.
Is it a red flag if a React vendor doesn't mention TypeScript?
For enterprise work, yes. TypeScript isn't mandatory, but the reasons to skip it in an enterprise context are rarely good ones. A vendor building for scale should be able to articulate a position on it. "We use TypeScript on all new enterprise projects because the refactoring safety is worth the overhead" is a fine answer. "We can do it if you want" is a mild flag.
What's the difference between hiring a React.js development agency and using staff augmentation to hire React.js developers directly?
An agency delivers outcomes — they own the architecture decisions, the team composition, and the delivery risk. Staff augmentation gives you people who work under your direction, which means you own those decisions. Both have legitimate use cases. Agencies are better when you need the outcome and don't want to manage the process. Staff augmentation is better when you have internal technical leadership and need capacity, not direction.
Top comments (0)