Choosing a Gatsby Development Agency: Questions That Matter

Choosing a Gatsby Development Agency: Questions That Actually Matter

Searching “gatsby development agency” and seeing wildly different pitches. Use this question set on tech stack, SEO, ecommerce and scale to filter real Gatsby specialists from generic React shops.

You’ve probably seen the pattern. One agency promises a fast Gatsby site. Another recommends a custom React build. A third presents a long list of tools without explaining why any of them fit your business.

The price difference can be just as wide.

The answer isn’t to pick the agency with the most technologies on its website. It’s to ask questions that expose how the team makes decisions, handles failure and supports the site after launch.

1. Start with proof they actually ship Gatsby at scale

A React agency isn’t automatically a Gatsby agency. A vendor that has built a few static marketing sites may not know how Gatsby behaves with frequent publishing, a large catalogue or complex data sources.

Start with delivery proof.

Ask for three live Gatsby projects with traffic levels, content velocity or ecommerce complexity comparable to yours. For each project, request Core Web Vitals reports, Lighthouse evidence and a clear explanation of the rendering approach. Was the site built with static site generation, server-side rendering or deferred static generation? Why did that choice fit the project?

Digiqt recommends checking both Gatsby mode expertise and measurable Core Web Vitals results in its guide to choosing a Gatsby development agency. That is more useful than a portfolio full of technology logos.

Ask what happened after launch. Did the site remain easy to build? Did publishing become slower as the content model expanded? Were any routes moved to another rendering mode?

You should also ask how many developers can independently design and ship a Gatsby build. Then ask which people will actually work on your account. An agency may have Gatsby expertise somewhere in the business, but that doesn’t mean it will be assigned to your project.

Gatsby’s own guidance for agencies and teams makes a related point. A repeatable stack and process matter if an agency wants to deliver consistently rather than reinventing each project.

Watch for weak answers. One small Gatsby site in the portfolio is not proof of specialist experience. Neither is the word “fast” without supporting data. The agency should also be able to explain why Gatsby was chosen instead of Next.js, another static framework or a traditional CMS.

2. Tech stack choices around Gatsby and why they picked them

A stack list isn’t an architecture. It’s only a list of ingredients.

Ask which CMS the agency recommends for your publishing model and why. Then ask what it would avoid. The right answer depends on how often editors publish, how many people need access and how structured the content is.

A marketing team that updates pages every day has different requirements from a team that publishes occasional campaign content. Editors need to know whether they can preview changes, schedule releases and update related content without asking a developer to repair references.

Ask how the agency structures Gatsby’s data layer. Does it rely mainly on Gatsby’s GraphQL layer, or does it add a separate backend or orchestration service? What happens when content from several systems needs to appear on one page?

For ecommerce, ask whether the team prefers Shopify, a headless commerce platform or a custom cart for your case. Don’t accept “it depends” as the final answer. Ask what it depends on. The relevant factors might include catalogue complexity, checkout control, inventory synchronisation and caching behaviour during traffic spikes.

Devkind’s checklist is useful here because it focuses on platform fit, code ownership and long-term cost, even though it isn’t Gatsby-specific. Read its questions about evaluating an ecommerce agency’s tech stack and adapt them to Gatsby.

Ownership needs a direct answer. Who owns the Gatsby codebase? Who controls hosting, deployment credentials and infrastructure configuration? Can your internal team make changes without paying the agency for every adjustment?

A tool salad is a warning sign. So is an agency that cannot explain the maintenance burden created by its preferred tools. Every integration adds another point of failure, especially when content, pricing or inventory must stay synchronised.

3. Rendering strategy for content and ecommerce, and how they decide

“Gatsby is fast” is not a rendering strategy.

Ask the agency to explain how it chooses between static generation, server-side rendering and deferred static generation. The answer should change by route and business need, not just by agency preference.

For editorial pages, ask which routes will be built ahead of time and which will be generated later. Then ask what happens as the page set grows. A build that works well for a small marketing site may become a publishing bottleneck once the content model expands.

For ecommerce, examine each major route separately. How will product listing pages work? What about product detail pages? Where will cart and checkout interactions run? Which data must be available at build time, and which must be fetched at request time or in the browser?

The agency should be able to describe a real tradeoff. For example, it might have moved a large category from full static generation to deferred generation or server rendering because builds were taking too long. Ask how it measured the result. Did publishing improve? Did response time or user interaction suffer?

The ecommerce hiring questions discussed in this community thread are broad, and the answers are not always technical enough for a buying decision. They still reveal the concerns buyers regularly have around stack choice, SEO and post-launch support.

The key failure mode is simple. An agency calls everything static, then discovers that the catalogue, personalisation or inventory rules do not fit that model. Gatsby can support mixed rendering approaches. Your agency should know when each one creates a benefit and when it creates operational cost.

4. Build pipeline maturity and real deployment metrics

“ We use CI” tells you almost nothing.

Ask the agency to walk through a deployment from a code change to production. Have them explain where tests run, where previews are created and how a failed build is reported. Ask which hosting and CI tools they use, then ask why those tools suit your publishing workflow.

Build caching deserves specific attention. How are dependencies cached? How is Gatsby data reused between builds? What happens when a content import changes a large part of the site?

Request anonymised metrics from a comparable project. Ask about typical build duration, failed build rate and how often the team had to change the content model to fix slow builds. You don’t need a perfect benchmark. You need evidence that the agency watches these measures and acts on them.

Preview workflows matter to editors. Ask how previews are generated and how many teams can work at once before the system slows down. A preview environment that works for one editor may become frustrating when several campaigns are under review.

Gatsby’s agency guidance links repeatable processes with predictable delivery and better commercial results. That makes process a buying concern, not an internal detail you can ignore.

Red flags include manual deployments, no staging environment and no monitoring for failed builds. A pipeline with no clear owner will usually become a problem during a large import or an urgent campaign launch.

5. Gatsby SEO, Core Web Vitals and migration safety

Gatsby can support strong SEO. It cannot make an SEO plan for you.

Ask for Gatsby projects where the agency improved Core Web Vitals and can show real reports rather than only laboratory scores. Ask which measurements came from field data and which came from testing tools. Synthetic scores are useful, but they don’t describe every visitor’s experience.

Then ask how the team handles structured data, sitemaps and international SEO. How will it prevent duplicate content from query parameters or faceted navigation? How will canonical URLs be generated and tested?

For a migration, request a URL mapping and redirect plan before development starts. Ask how internal links will be preserved, how broken links will be found and what search monitoring will run after launch.

Rendering decisions belong in this conversation. Has the agency seen crawl or indexing issues on large server-rendered sections? If so, what caused them and how were they fixed?

For a more detailed view of how Gatsby SEO works in practice, technical leads should examine the relationship between rendering, structured data and internationalisation before approving the architecture.

“Gatsby is fast, so SEO is fine” is not an answer. Neither is a redirect spreadsheet produced during the final week. SEO depends on routing, content structure and deployment behaviour. Those decisions need to be made together.

6. Architecture for scale, multilingual and content velocity

Ask the agency to model what happens after launch.

Give it realistic growth assumptions about content, locales and traffic. Then ask how it would design collections, taxonomies and GraphQL queries so that new sections don’t cause a sharp increase in build time or query complexity.

Multilingual architecture needs a direct recommendation. Would the agency use separate sites, locale-aware routing or a CMS-driven locale model? Each approach affects editorial work, URL structure and deployment behaviour.

Ask how translations are created and linked. What happens when one locale publishes before another? Can editors reuse shared content without creating accidental duplication? How are translated metadata and structured data maintained?

Content velocity also affects infrastructure cost. A team that publishes frequently may need more builds, more previews and more cache management. Ask how the agency would keep that affordable without making editors wait for every change.

This is where total cost of ownership matters. Devkind’s discussion of platform fit and ongoing cost gives buyers a useful way to question the long-term effect of technical choices, even though the article is aimed at ecommerce agencies rather than Gatsby teams.

A weak architecture assumes that adding more build capacity will solve every problem. It won’t. Poor data modelling, inefficient queries and unnecessary rebuilds eventually require a design change.

7. Team, process, support and long-term ownership

Before signing, identify who owns each important part of the system. That includes Gatsby configuration, the CMS schema, deployment settings and infrastructure access.

Ask who will make technical decisions during the build. If the senior specialist appears only during the sales process, ask who replaces that person after handover.

Post-launch support needs the same level of detail. What happens if a failed build blocks publishing? Who responds if a deployment affects checkout? How are incidents reported, escalated and documented?

The ecommerce hiring discussion on Reddit reflects concerns that apply to Gatsby projects too. Buyers want to know about ongoing SEO, support after launch and what happens when the first production problem appears.

Ask about hosting, licences and maintenance costs over the future life of the site. Ask what documentation you’ll receive if you move to another supplier. The code should not be the only handover asset. You also need deployment instructions, content rules and an incident runbook.

If you’re still comparing Gatsby with other Jamstack choices, Choosing a Jamstack agency beyond the buzzwords gives broader context for judging agencies that sell a similar set of ideas under different technology names.

The biggest warning signs are hidden implementers, undefined support promises and no written process for outages. An account manager can coordinate communication, but they cannot replace clear technical ownership.

Start your agency shortlist with evidence, not presentation quality. Send each candidate the same questions. Compare the answers on rendering decisions, build behaviour, ownership and post-launch support. The right agency won’t simply say Gatsby is a good fit. It’ll show where Gatsby fits, where it doesn’t and what it will do when the original assumptions stop holding.