Gatsby development services
Gatsby development for teams that still have a Gatsby site to run — and maybe one to migrate
· Average time to first merged PR: 10 to 14 days
Gatsby is not the default choice for new projects anymore, and anyone who tells you otherwise is not paying attention. But there are thousands of production Gatsby sites — marketing pages, docs portals, headless storefronts, knowledge bases — that still ship value every day, and they need people who know the framework well enough to maintain, upgrade or move them gracefully.
Siblings Software is a small Argentine firm that has been shipping Gatsby work since v1 and now spends most of its Gatsby hours on three jobs: keeping existing v4 and v5 sites healthy, upgrading v3/v4 codebases to v5, and running honest Gatsby-to-Next.js migrations for teams that have outgrown static generation. This page is written for the buyer comparing vendors: what the work looks like, what it costs, and when we would tell you Gatsby is the wrong tool.
Who actually hires a Gatsby team from us in 2026
Four buyer profiles account for almost all of our Gatsby engagements.
Marketing and DevRel teams running content-heavy Gatsby sites
A marketing site, a docs portal or a developer blog built on Gatsby three or four years ago. Content editors work in Contentful or Sanity. The site is fast and ranks well, nobody wants to rebuild it, but the build takes 14 minutes, the plugins are a version behind and the last engineer who knew gatsby-node.js has left. You want a steady pair of hands, not a rewrite.
Headless commerce teams on Shopify, BigCommerce or a custom backend
The storefront is Gatsby, the PIM is headless, the payments flow runs on a hosted checkout. You want better LCP on PDPs, faster incremental builds when a buyer updates a product title, MDX support for landing pages, and someone who can write a Shopify source plugin without three weekends of archaeology.
Product teams planning a Gatsby-to-Next.js move
The reasons are usually two: builds have grown past the deploy window, or the product needs more live data than static generation gives for free. You want a team that can run the migration in parallel with your roadmap, preserve SEO (redirects, canonicals, structured data), and not invent a third framework along the way.
Agencies with a Gatsby backlog they cannot staff internally
You signed clients on Gatsby in 2020 and 2021, the sites are still live, but your junior engineers only know Next.js. Churning the accounts is not an option and neither is a rebuild every time a theme tweak is requested. You want a white-label Gatsby bench that ships through your issue tracker and shows up on your Slack.
If none of those describe you, we will still take the call — and say so in the first fifteen minutes if Gatsby is not the right fit for what you are trying to build.
What Gatsby engineers actually ship each sprint
Most service pages stop at “we build Gatsby sites.” That is not useful when you are trying to choose a vendor. The scope below is what a typical Gatsby engineer works on in a given sprint. The mix shifts per engagement, but rarely are fewer than four of these areas in play.
Content-driven front ends in React and GraphQL
Page templates, component libraries, MDX shortcodes, typed GraphQL queries with gatsby-plugin-typegen or codegen. The page APIs in gatsby-node.js are treated like code, not a graveyard: tested, documented, and reviewed when they change. When we add new content types the editors see them in the CMS within a day.
Headless CMS integration without the ceremony
Contentful, Sanity, Prismic, Strapi, Storyblok, Hygraph and WordPress via gatsby-source-wordpress or WPGraphQL. Shopify and BigCommerce for headless commerce. We handle preview environments properly — editors should see their draft in seconds, not ten minutes — and we write custom source plugins when the off-the-shelf one has gaps.
Rendering strategy: SSG, DSG and SSR in the right places
SSG for pages that do not change between deploys, Deferred Static Generation for the long tail (archive pages, old blog posts, product detail pages for slow-moving SKUs), and SSR for the handful of routes that genuinely need per-request data. Incremental builds are configured so a single CMS edit does not rebuild 40,000 pages.
Image and media pipeline
gatsby-plugin-image with AVIF and WebP, sensible art direction for mobile, and a DAM connector (Cloudinary, imgix or the built-in Sharp pipeline) depending on what the content team already uses. Lazy loading done correctly so LCP images are not penalised. Video and poster frames are preprocessed at build time, not at runtime on the user’s phone.
Core Web Vitals and SEO, treated as engineering work
Per-template LCP budgets, CLS audits before and after every release, structured data kept in sync with the CMS model, sitemap and hreflang hygiene, canonical rules that match the routing. We track Search Console coverage per template and raise indexation regressions in the same place we raise type errors — because an unindexed page is just as broken as a page that throws.
Upgrades and migrations, without freezing the roadmap
v3 or v4 to v5. Node 18 across CI and hosting. React 18 in the front end. Or, when the cost model has shifted, a bounded Gatsby-to-Next.js migration with redirect maps and SEO parity. We do not pitch rewrites when an upgrade will do, and we do not defend Gatsby when Next.js is plainly the better fit.
Every senior we place has shipped at least one production Gatsby site from scratch, owned at least one major upgrade, and carried at least one site through a migration. Most have all three, across marketing, SaaS docs, headless retail and publishing.
Engagement models and what they cost
We publish ranges because hidden pricing wastes everyone’s time. The final number depends on seniority mix, English fluency (some buyers pay a premium for engineers who are comfortable facing their own stakeholders directly), and whether the brief needs a specialist — a performance engineer, a headless commerce lead, or someone who has migrated three Gatsby sites to Next.js already.
Gatsby specialist
One senior engineer embedded in your team. Good when the engineering org is solid and you need one more pair of hands that already knows Gatsby v5, gatsby-node page APIs and the quirks of your CMS. Pairs with your team on the hardest parts, owns one slice of the site, attends your stand-ups.
Price: USD 6,500 to 11,000 per month. Minimum: 3 months.
Product squad
Three to five engineers (senior and mid mix) with a tech lead, QA automation and part-time DevOps. Delivers features, owns the component library, keeps the build honest and the Vitals green. Works alongside our dedicated Gatsby development team page for scope references, or combined with our React team and Next.js team for specific stack bias.
Price: USD 20,000 to 38,000 per month. Minimum: 4 months.
Modernization squad
Two to four engineers focused on a bounded goal: v3/v4 to v5, a Core Web Vitals intervention, or a Gatsby-to-Next.js migration. Often runs alongside your feature team rather than instead of it. Hands over when the scorecard is green — we do not linger.
Price: USD 15,000 to 28,000 per month. Minimum: 3 months.
Numbers assume 40-hour weeks and include recruiting, benefits, laptops and local taxes. Third-party services — Netlify, Vercel, Contentful, Sanity, Cloudflare, Sentry — stay on your accounts so you keep control of data and billing.
The modernization path we actually use
Two-thirds of our Gatsby work starts with a site that was built on v3 or v4, has drifted out of support, and is either heading for v5 or planning a move to Next.js. The sequence below is what we use. Every phase ends with a deployable state; nobody signs off on a ten-week rewrite with nothing in production until week nine.
- Baseline audit (week 1). Build-time profiling, bundle analysis, a full plugin inventory with compatibility notes, a redirect map derived from the current URL structure, and a Core Web Vitals baseline for the ten most-trafficked templates. Output: a risk map per template and per plugin, so nobody is surprised in week six.
- Upgrade v3/v4 to v5 (weeks 2–4). Node 18, React 18, parallel query execution, plugin upgrades or replacements, tsconfig cleanup when applicable.
gatsby-plugin-imagenormalisation. The site stays green in CI throughout; we merge in small, reversible slices, not one giant PR. - Data layer and images (weeks 3–6). GraphQL schema cleanup, removing dead source plugins, normalising image handling into a single approach (built-in or DAM), and wiring preview environments that actually work for content editors. By the end of this phase, editing a page in the CMS should feel instant in preview and predictable in production.
- Core Web Vitals and SEO (weeks 4–8). LCP budgets per template, CLS elimination, INP audits, critical CSS where it earns its keep, and structured data aligned with the CMS model. Search Console coverage is reviewed per template; indexation regressions get their own backlog. This is the phase that moves the metric Google ranks on.
- Optional Next.js migration (weeks 6–12). Only when it is the right call (see the section below). Route-by-route parity in Next.js App Router, redirects tested in staging with a crawler, image pipeline reimplemented with
next/image, and a cutover that uses Vercel or Netlify redirects so no 301 is ever in doubt. Post-cutover we watch Search Console for two weeks and roll forward.
Timeline above fits a 150 to 1,500 page site with one headless CMS. Bigger estates — multi-region, multi-brand, multi-CMS — mostly extend phases 3 and 5. We have not seen a modernization that required stopping feature work, and we would push back if a client asked for one.
Should you still be on Gatsby? An honest read
We get paid either way, so here is the unvarnished version. Since Netlify acquired Gatsby Inc. in 2023 and folded Gatsby Cloud into the Netlify platform, community momentum has clearly shifted to Next.js for new builds. That does not mean Gatsby is dead; it means the decision is a cost-benefit read, not a fashion one.
Keep Gatsby if…
- The site is content-dominant: docs, marketing, blogs, a catalog that does not change on every request.
- Your team is productive in it and your deploy window can absorb the build time you have today.
- You have invested in custom source plugins or page creators that encode real business logic.
- Editors are happy with the preview flow and nobody is complaining about time-to-publish.
- The image pipeline you have (AVIF/WebP + responsive) is already delivering the LCP you need.
Move to Next.js if…
- Build times have outgrown the deploy window and incremental builds do not close the gap.
- You need per-request personalisation or data fresh to the second on a meaningful share of pages.
- Your team owns Next.js elsewhere and two frameworks is the real cost, not the code.
- You want App Router patterns: server components, streaming, route-level caching with explicit invalidation.
- Hiring in your market is easier for Next.js than Gatsby, and you plan to staff internally within 12 months.
If the answer is genuinely unclear, we run a paid one-week audit that ends in a written recommendation. The audit cost is credited against the first month of any squad engagement that follows. About 40% of audits end with “stay on Gatsby, here are the eight things to fix”, which we are happy to staff.
Gatsby with us vs freelancer, in-house or generic offshore
Most prospects have already tried at least one of the alternatives below. Here is an honest comparison. If a row does not match what you have seen, say so on the first call and we will adjust the framing.
Where a freelance Gatsby developer wins
Scoped tasks. A custom source plugin for an obscure CMS. A theme tweak nobody can get quite right. A one-off script to regenerate sitemaps. If the work is under roughly 80 hours and well-defined, a specialist freelancer is usually cheaper and faster.
Where a freelancer hurts
Continuity. They juggle three other clients, take holidays without warning, and seldom do the unglamorous work that keeps a Gatsby site healthy: dependency upgrades, plugin pinning audits, Storybook hygiene, accessibility regressions, CI speed. You ship tickets fast and the platform rots in parallel.
Where an in-house hire wins
Long-term ownership. If the Gatsby site is central to your product for the next three years and you can afford a three-month search, a full-time senior is irreplaceable. Plenty of our clients start with us, see what “good” looks like, and then hire internally. That is a healthy outcome, not a loss.
Where in-house hurts
The 2026 hiring market for engineers who actively want to work on Gatsby is thin. Most senior React developers will ask why you are not on Next.js in the first interview. If the hire turns out wrong at month six you are looking at severance, not notice, and the roadmap stalls while you search again.
Where large offshore agencies win
Warm bodies at low rates when the work is genuinely generic: CMS skins, template tweaks, data-entry UIs. If the brief really is “give me ten Gatsby developers and assign them tickets”, they are built for it.
Where large offshore agencies hurt
The engineer in the interview is rarely the one in the commits. Timezone overlap with the US tends to be two to four hours. Core Web Vitals work, structured-data hygiene and plugin governance are treated as extra scope rather than defaults. Notice periods are 30 to 90 days, which makes ramp-down painful when a project ends.
Where we fit in
Between the two. Small, senior, full-time employees in a timezone that overlaps a full US business day. You interview the exact engineer who will work on your site. Upgrades, performance, SEO and accessibility are part of the default scope, not an upsell. Minimum commitments are three to four months, not a year.
For narrower gaps, our Gatsby staff augmentation service is usually the better fit — same engineers, different commercial model.
Real Gatsby scenarios we see repeatedly
These are composites from recent engagements. Details anonymised, numbers rounded, but the shapes are accurate. They are here because buyers usually want to know whether their situation is a thing we have dealt with before.
Scenario A — the marketing site with 18-minute builds
Context. US SaaS company, Gatsby v4, Contentful backend, 3,200 pages after a content expansion into four locales. Build time had drifted from four minutes to eighteen. Every campaign launch required a build freeze, which marketing hated.
What we did. A two-person squad for nine weeks. Upgraded to v5 with parallel queries, rewrote three legacy source plugins as single typed queries, moved the long-tail archive to Deferred Static Generation, and pinned the image pipeline to a single code path. No CMS schema changes.
Outcome. Build time dropped from 18 minutes to 3 minutes 40 seconds. Incremental builds for a single content edit took 45 seconds. Marketing stopped asking for a rewrite.
Scenario B — the headless Shopify storefront with an LCP problem
Context. UK-based DTC brand, Gatsby v5 storefront consuming Shopify via a custom source plugin. LCP on PDPs was 3.6 seconds on mid-range Android. Conversion on mobile was visibly lagging behind desktop.
What we did. A single senior specialist for ten weeks. Reworked the hero image pipeline with proper art direction, moved the review widget to a client-only island, introduced per-template LCP budgets wired into CI, and rewrote the Shopify source plugin to avoid a known N+1 pattern on variants.
Outcome. LCP on PDPs dropped to 1.8 seconds at the 75th percentile. Mobile conversion recovered most of the gap to desktop over the following quarter. No brand or design changes were required.
Scenario C — the docs portal that outgrew static generation
Context. Developer-tools startup with a 1,100-page docs portal in Gatsby v4. Most of it truly static, but a new API explorer needed live OpenAPI data and per-user examples. Trying to bolt SSR onto the existing site was making the build brittle.
What we did. A three-person modernization squad for twelve weeks. Migrated the portal to Next.js App Router route by route, kept the existing MDX authoring flow via a shared content package, rebuilt the image pipeline on next/image, and set up redirect tests that ran on every PR.
Outcome. Zero SEO regressions in the first 30 days post-cutover. Indexation held at 99.1% of the original set. The API explorer shipped on top of Next.js server components. The team kept shipping docs throughout.
Scenario D — the agency with a Gatsby backlog
Context. A Canadian digital agency with nine live Gatsby sites built between 2020 and 2022. Their junior engineers only knew Next.js. Client tickets were piling up in the Gatsby queue and the senior who used to own it had moved internally.
What we did. Two senior engineers on a rolling staff-augmentation model for seven months. White-labelled on the agency’s Slack and issue tracker. Triaged the backlog, set up weekly dependency upgrade windows across all nine sites, and ran two v4-to-v5 upgrades as discrete sub-engagements.
Outcome. The backlog cleared in the first six weeks. Client retention on the affected accounts stayed at 100% over the engagement. The agency later hired one of our engineers full-time at month eleven.
Mini case study
How a publisher cut Gatsby build time from 22 minutes to 4 and held SEO through a Next.js cutover
Client. A European lifestyle publisher running a Gatsby v4 content site on Contentful. Roughly 4,800 articles, six locales, a steady 2.3 million monthly organic sessions. Build time had grown from six minutes in 2021 to twenty-two minutes by late 2025, and a rebuild was blocking every CMS-driven release.
Brief. Stop the build pain, and evaluate whether the site should stay on Gatsby or move to Next.js within twelve weeks. If it moves, no organic traffic loss is acceptable.
What we did. A three-person modernization squad, one tech lead plus two senior engineers. Week 1 produced a 14-page audit with a clear recommendation: upgrade to v5 first to stabilise the build, then reassess. Weeks 2 to 4 landed the v5 upgrade with parallel queries, reducing build time to 6 minutes 10 seconds on the same infrastructure. That bought us room. Weeks 4 to 8 we ran Core Web Vitals work on the top 40 article templates, trimmed four legacy plugins, and moved older content to DSG. After that, with builds at 4 minutes and CWV green, the CTO decided to move to Next.js anyway, because the in-house team already owned three other Next.js products. Weeks 6 to 12 ran the migration in parallel with continued publishing: App Router, next/image, MDX via a shared content package, full redirect map tested with a crawler on every PR, and a Friday-evening cutover using Netlify then Vercel redirects. Search Console was monitored daily for 30 days post-cutover.
Result. Build time dropped from 22 minutes to 4 minutes on the final Gatsby iteration, then stabilised around 2 minutes 30 seconds on Next.js. Organic sessions the month after cutover were 101.3% of the prior month — essentially flat, well within noise. Indexation coverage held at 99.6% of the pre-migration set at the 30-day mark. The in-house team took over at month four; we stayed on for one day a week in month five to handle tail-end redirect issues.
Honest caveat. Weeks 1 to 3 felt slow from the outside. Audits and upgrades do not produce demo-able features, and the CEO asked twice why there was “nothing new to see”. If you compare velocity by features-shipped in month one, this engagement looks worse than a freelancer. By month two the compounding showed up.
At a glance
Industry: Lifestyle publishing, 6 locales
Engagement: 3-person squad, 12 weeks + tail
Stack: Gatsby v4 → v5 → Next.js, Contentful, Netlify, Vercel
Build time: 22 min → 2 min 30s
Organic sessions post-cutover: 101.3% of prior month
Indexation coverage: 99.6% held
The risks of outsourcing Gatsby work, and how we handle them
Any vendor telling you outsourcing Gatsby work is risk-free is either inexperienced or selling. Here are the four failure modes we see most often, and the specific controls we use against each.
Risk: SEO regressions slip in during an upgrade or migration
How we handle it. A redirect map is produced in week one and tested on every PR with an automated crawler. Canonical rules, structured data and sitemap outputs are diffed between old and new builds. Search Console coverage is checked per template, not per site, so a single regressed route type surfaces immediately instead of hiding in an aggregate.
Risk: the engineer looks strong on paper and stalls in week three
How we handle it. Vetting ends in a live pair session on a real Gatsby issue — a source plugin query that does not resolve, a gatsby-node.js createPages that silently drops slugs — not a Leetcode puzzle. Two-week free replacement window. On day 14 the account lead asks you one question: “if this were a full-time hire, would you keep them?”. In the last 18 months we have swapped two engineers, both inside the free window.
Risk: knowledge walks out when the engagement ends
How we handle it. Documentation is a line item, not a favour. Architecture Decision Records for non-obvious choices (why DSG here, why a custom source plugin, why this caching key), READMEs for every plugin we write, runbooks for the deploy and rollback procedures. If you end the engagement tomorrow, the internal team has a map, not a scavenger hunt.
Risk: Core Web Vitals drift quietly after the “big push”
How we handle it. LCP, CLS and INP budgets are expressed per template and wired into CI. A budget failure blocks merges the same way a type error would. Real-User Monitoring numbers are reviewed in the weekly ops call alongside engineering progress, so performance regressions get triaged by the same people who ship features.
Why Siblings Software specifically
Decide based on facts, not slogans.
11+
Years building React and Gatsby sites
Founded 2014 in Córdoba, Argentina
40+
Gatsby projects shipped or modernized
Publishing, SaaS docs, headless retail
GMT-3
Argentina timezone
Full same-day overlap with US Eastern
We are deliberately small. There is no sales organisation chasing headcount. Javier Uanini still takes most discovery calls personally and reviews every Gatsby engagement with the tech lead assigned. Our engineers talk to clients directly from week one. That is the actual reason onboarding is fast: there is nobody in the middle translating requirements.
Things buyers usually get wrong when shopping for a Gatsby vendor: asking for an hourly rate before explaining the work (you will be quoted the lowest possible number, and the real cost will arrive as change orders later), assuming any React developer can pick up Gatsby in a week (the data layer and page APIs take longer than that), and believing a bigger agency means more reliable delivery (in Gatsby work specifically, small and senior beats large and generic almost every time, because the framework rewards people who have lived with it).
For context, the official Gatsby documentation is the baseline we teach against, the web.dev Core Web Vitals guidance is the yardstick we measure performance on, and the official v4-to-v5 migration notes are the first thing a new engineer on your project reads, not the last.
Frequently asked questions from buyers
gatsby-node page creators or unusual GraphQL resolvers extend the middle phase, not the overall shape.gatsby-source-wordpress or WPGraphQL. Shopify and BigCommerce for headless commerce. Markdown and MDX. Airtable and Notion for smaller content operations. We can also write a custom source plugin when the CMS is internal or there is no off-the-shelf option.Our standards
Gatsby treated like production software, not a static-site demo.
- Build time is a budget, not a side effect. Per-template LCP budgets and an overall build-time budget are wired into CI. A blown budget blocks merges the same way a failing test would.
- Redirect maps are produced on day one. Before any migration work lands, the redirect map exists, is under version control, and is tested on every PR with a crawler.
- Plugins are pinned and reviewed. No silent major upgrades. The plugin inventory is documented with a compatibility note per dependency, updated on every quarterly maintenance pass.
- Preview environments work. Editors should see their draft in seconds, not in a 20-minute build. If preview is slow, it is a bug, not a feature request.
- Structured data matches the CMS model. When an editor adds a field, the schema updates. We do not let
JSON-LDdrift from the source of truth. - Written artefacts. ADRs for non-obvious choices, READMEs per custom plugin, runbooks for deploy and rollback. The handover is a file tree, not a call.
Talk to Siblings Software
Tell us about the site, the team and what you need. We reply within one business day, or say so if we are the wrong fit.